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”.
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’.
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''.
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 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?
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?
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.
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.
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.
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/