3. The Symptoms
“In the first week of each Sprint, we testers don't have much
to do. Then we are going crazy the last few days.”
“The developers don't have much to do in the last few days
of each Sprint, so they are usually getting started on the next
Sprint.”
“It's not unusual for the team to have nothing that is
deliverable at the end of the Sprint. Everything's been coded,
but the testing isn't done.”
3
4. The Practice
4
Vast majority of our work gets done at the very end of each sprint. Meaning, this
is when it gets accepted by the Product Owner and meets the Definition of Done.
14-
Sep
15-
Sep
16-
Sep
19-
Sep
20-
Sep
21-
Sep
22-
Sep
23-
Sep
26-
Sep
27-
Sep
SP Delivered 0 0 0 0 0 0 0 10 1 0
0
2
4
6
8
10
12
Team A – Sprint Y
31-
Aug
1-
Sep
2-
Sep
5-
Sep
6-
Sep
7-
Sep
8-
Sep
9-
Sep
12-
Sep
13-
Sep
SP Delivered 0 0 0 0 0 0 0 0 8 15
0
5
10
15
20
Team A – Sprint X
14-
Sep
15-
Sep
16-
Sep
19-
Sep
20-
Sep
21-
Sep
22-
Sep
23-
Sep
26-
Sep
27-
Sep
SP Delivered 0 0 0 0 0 0 0 3 0 13
0
2
4
6
8
10
12
14
Team B – Sprint Y
31-
Aug
1-
Sep
2-
Sep
5-
Sep
6-
Sep
7-
Sep
8-
Sep
9-
Sep
12-
Sep
13-
Sep
SP Delivered 0 0 0 0 0 0 0 0 11 6
0
2
4
6
8
10
12
Team B – Sprint X
5. The Solution
5
“Stop starting and start finishing.”
-- A Sprint Is Not a 2-Week Waterfall!, Agile Coach Journal
“A team should always work to overlap work
as much as possible.”
-- An Iterative Waterfall Isn't Agile, Mountain Goat Software
6. The Principles
6
There are three key principles for how to avoid waterfalling a sprint:
• Smaller batch sizes
• Less work in progress (on different stories)
• Swarming (more parallel work on a single story)
“Scrum recognizes no titles for Development Team members other than
Developer, regardless of the work being performed by the person; there are no
exceptions to this rule.”
“Scrum recognizes no sub-teams in the Development Team, regardless of
particular domains that need to be addressed like testing or business analysis;
there are no exceptions to this rule.”
“Individual Development Team members may have specialized skills and areas of
focus, but accountability belongs to the Development Team as a whole.”
-- Scrum Guide, The Development Team
7. The Approach
7
General approach on how to get it done in practice:
1. Split your stories into the maximum number of smallest usable items;
2. Know the order of priorities for delivering work within a sprint;
3. Identify as many independent tasks for each of the user stories as possible;
4. Swarm on a top priority story and get it done as soon as possible, then
repeat with the next priority.
9. The Benefits
9
• It limits risks down to the lowest priority story in a sprint.
• It encourages teamwork and collective accountability.
• It provides Product Owner with an early feedback and adds predictability for
the sprint outcome.
• It makes people’s work more productive – less time spent waiting for
something.
• It reduces stress at work by eliminating work load extremes.
• It promotes cross-functional behavior within a team and fosters knowledge
sharing and skills development.
10. The Difficulties
10
• It’s not always possible to have many independent tasks for a story.
• It requires a lot of communication and coordination within a team.
• It may cause some additional work to be needed to incorporate different parts
of the result into a single common solution.
• It may seem counterintuitive to postpone any other work until the higher priority
story is done, which may cause some people to think this adds risks and resist
accepting the new approach.
11. The Considerations
11
In general, there are two major issues with how we tend to deliver results:
• Process staging. I.e., the design > code > review > test pattern.
• Silos within our development teams. People having too narrow/strict roles and
functions assigned to them.
The goal is to eliminate those “staging gates” wherever possible and have truly
cross-functional teams.
Some practical things to consider in order to achieve that:
• Pair programming – review code at the same time of writing it;
• Pair testing – close collaboration, knowledge transfer, exchange of
perspectives and early feedback;
• Reverse development (e.g., TDD) – have means to test before implementation.
Won’t necessarily parallelize work, but will help escape the waterfall approach.;
• QA specialists who can code and programmers willing to test – increased
flexibility when distributing work, especially to automate the testing;
• Knowledge sharing sessions – so anyone can work on any part of your
system.
12. The Anti-Patterns
12
“If we can’t finish up with the testing reaching this state of development late in a
sprint, then let’s just move all of the testing to the next sprint so people who do
the testing can start right away from the beginning of it.”
• That’s just a bigger waterfall that spans across several sprints instead of one;
• People are working as two separate teams: testing and coding on their own;
• Nothing is really done at the end of a sprint – quality is not verified.
“Let’s do a lot of upfront thinking on a story to document everything thoroughly
and it great detail, so developers can spend less time dealing with any questions
that may arise during a sprint.”
• This may produce a lot of waste as requirements and priorities tend to change and we
need to embrace this;
• It’s developer’s prerogative to answer the “How?” question, don’t need to document
that with the requirements;
• We’re avoiding close and daily collaboration with a PO instead of encouraging it.
14. The References
14
“A Sprint is Not a 2-Week Waterfall!”
http://www.agilecoachjournal.com/2014-02-03/a-sprint-is-not-a-2-week-waterfall
“Agile Testing: No Mini-Waterfalls!”
http://blog.projectconnections.com/alan_koch/2015/01/agile-testing-no-mini-
waterfalls.html
“An Iterative Waterfall Isn’t Agile”
https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile
“Avoiding Mini-Waterfalls”
http://www.allaboutagile.com/avoiding-mini-waterfalls/
“Helping Your Scrum Team Avoid a Waterfall Mentality”
https://www.352inc.com/blog/helping-your-scrum-team-avoid-a-waterfall-mentality/
“Scrum’s Sprints Are Not Mini-Waterfalls”
http://brainslink.com/2011/07/scrums-sprints-are-not-mini-waterfalls/
