Stop 'Waterfalling' Your Sprints
Basic
difficulty
Stage 2
Agile IQ® Level
PBIs
Practices
Agile
Framework
Introduction
When work doesn’t get finished in a Sprint, the temptation is to “roll it over” into the next Sprint. A better approach is to learn to slice work so that it does fit into a Sprint.
Slicing Backlog items like a cake – thin, vertical slices, is considered “best practice”.
What is 'Waterfalling Sprints'?
When work extends beyond the Sprint boundary it’s often because tasks, such as development or testing, continue til they’re finished instead of being able to be completed within the boundaries of the Sprint.
This is called ‘Waterfalling your Sprints’.
Don't Waterfall your Sprints
If you're breaking up Backlog items by task, so that you're doing development in one Sprint and then testing in another, you're Waterfaling your Sprints. Try, instead, to break up large backlog items end-to-end by feature - a technique known as 'vertical slicing''.
Try This
Start with improving estimation
If the item can’t be delivered in a single Sprint, then the team needs to break it down into smaller pieces. Each slice needs to be able to be completed, and achieve the Definition of Done, by the end of the Sprint.
Look at your estimations at Sprint Review:
Is the item too large?
Is the total cycle time in days more than the Sprint length? What causes the team to think they can finish it within the Sprint boundaries? Are the estimations within the team's normal range or does work always take longer than expected?
Do items start too late in the Sprint?
Is the cycle time small, but the item starts too late? Should it have started earlier in the Sprint? What can you do next time to ensure the item starts earlier?
We didn't finish all the testing
Is there too much testing to be done? Is this what causes the item to not be finished in the same Sprint as the development work? This is a good candidate for further slicing so both development and testing work is less.
Look at the Definition of Done (DOD)
- What does the Definition of Done say we need to do as a team to make the item ‘potentially releasable’?
- Are we doing more than is required by the Definition of Done?
- Are we doing everything that’s needed, but we’re not slicing the work effectively? E.g. there’s just too much testing?
Investigate different slicing methods
- Experiement with different methods to turn large Backlog items into smaller ones.
- Start with vertical slicing.
- Avoid horizontal slicing.
- Record cycle time to see how long it takes the team to deliver the smaller items do Done.
- Assess the new methods in the Retrospective.
Don’t know how to slice? Do a spike!
Spikes are research tasks that help teams understand what’s required to slice an item into smaller pieces. Imporantly, a spike is timeboxed to a few hours.
Once the spike’s timebox ends, the team should gather to report on their research and the method they’ve chosen to slice the work.
A Spike isn't upfront design or requirements gathering. It's research.
People are often tempted to do a spike to give them more comfort regarding scope boundaries. Teams will often say 'there are too many unknowns' as a reason for doing a spike.
Only do a spike to research a method for slicing work into smaller pieces when the team have no existing methods available to them.
Spikes are part of Backlog Refinement in Scrum. They are not defined as Backlog items as they don't deliver user value.
References
1. Wake, B. (2003). INVEST in Good Stories, and SMART Tasks. Xp123. Online at: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
