Have you ever encountered a situation such as the title of this article? I am sure you have and possibly experience this often. So, how do you deal with incomplete stories in a Sprint?
Do the managers in your company make a big issue out of it? How do you manage unfinished work during the Sprint planning meeting?
If you have experienced any of the above, this article will help you to manage the spillover effectively.
Unfinished work and Spillovers
It's quite common for a team to have some unfinished work occasionally. However, if this happens often, I suggest you evaluate the root causes and find ways to reduce or avoid the spillovers altogether.
You don't need to worry; below, you will find an overview of incomplete sprints, better known as spillovers, and how to best deal with them, user stories examples, etc.
What are Spillovers & DoDs?
A spillover is a backlog item that failed to meet the criteria defined in the Definition of Done (DoD) for the project team. It is important to note that the DoD is defined for the entire project and applies to any user story.
Causes of unfinished work
Some of the most common reasons are:
- You overestimated what you could complete in one sprint.
- Tickets were much larger than you anticipated.
- A work item became blocked, e.g., due to environmental issues or unmet dependency.
- Unplanned reduction in the team capacity, such as a team member becoming ill mid-iteration, affecting existing commitments.
- Change in priorities: Unplanned work came into the iteration.
- Unforeseen scenarios.
- Problems with DoD: The DoD wasn't accurate, and you figured that out too late.
- Consequently, when you're at the sprint end, you cannot reach "Done."
Managing unfinished work
It's important to devise strategies to manage such unfinished work and to review the process followed by the team during the sprint retrospective session. This session can be used to identify the root cause for spillovers and to discuss options available to mitigate it.
Now, the question is, should we keep the same story point estimate or reduce it? Your approach depends on what you'd like to achieve.
Should you prioritize the future of the user story?
If the answer is yes, and If you are trying to stabilize the velocity for the team, it might be worthwhile to figure out the appropriate size for the pending work over transferring the whole estimate.
You have already decomposed the story to the most granular level during refinement, and it is just a matter of getting it done. Again, if the story was done partially, the team needs to discuss the remaining work to mark the story as done.
Remember this is a workaround, and you must try to avoid spillovers, but if they happen, you can do the following:
- Create a "Velocity Amendment" label to track completed story points, including any spillovers. This workaround can help track team efforts but may not reflect value delivery. Re-estimate the original story with the remaining points for the next sprint's completion.
- Alternatively, use a custom field called "Original Estimate" to input data about the initial estimation and utilize the Story Points field for the new estimation. Generate a report and compute the velocity from the previous sprint by subtracting the Original Estimate from the Story Points value to get the amount of completed work.
Another approach is to carry over the entire story without considering the work partially done as part of the velocity. This is more of a purist approach. Partially done work is separate from an Increment because that would reduce transparency to progress and limit the ability to release value and get meaningful feedback.
If there is partially done work towards the end of a Sprint, it needs to be removed from the Increment so that the Increment meets the Definition of Done. The downside might be the misappropriation of velocity to measure team productivity.
If not a priority, move the story to the bottom of the product backlog. The story will get evaluated for priority during the backlog refinement session and be moved up or down the backlog as relevant.
The key takeaways
It is important to review the process followed by the team during the sprint retrospective session. This session can be used to identify the root cause for spillovers and to discuss options available to mitigate it.
As a Scrum Master, you must understand the team's availability for the entire sprint duration and plan the amount of work that can be taken up accordingly. By doing this, you can minimize/avoid the spillover.
Having a clear Sprint goal and including a buffer in the capacity plan for unplanned work is always helpful. Remember to validate committed stories against available team capacity, and be sure to increase the time spent on sprint planning.
Poor planning may and most likely will result in spillovers.
