If you've ever wondered what a spillover is, it's a backlog item that doesn't meet the Definition of Done (DoD). If you are a Scrum Team member, product owner, or a stakeholder, spillovers might trouble you in sprint planning meetings. When this happens, you will spend a lot of time discussing the details and planning for these unfinished stories.
It's quite common for a team to have some unfinished work occasionally. However, if this happens often, I suggest that you evaluate the root causes and find ways to minimize or avoid the spillovers. Here are a few recommendations to help control the situation.
Causes of unfinished work
- You overestimated what you could complete in an iteration.
- One of the work items was much larger than you anticipated.
- A work item became blocked (e.g., as the result of environmental issues or because a dependency was not met).
- A team member became ill mid-iteration, affecting existing commitments.
- Service injections/unplanned work came into the iteration.
- The DoD wasn’t accurate, and you figure that out too late. Consequently, when you're at the sprint end, you are not able to make it to "Done."
Managing unfinished work
Recommendations for controlling and organizing the unfinished work:
- Understand the root cause and how to avoid it. Use the retrospection to evaluate the cause and learn from it.
- Discuss the future of the user story. Is it still a priority?
- If the story is a priority, don’t spend time breaking it down the story further. The team is familiar with the story details and therefore moving the same story to the next sprint should be helpful.
- If the story is not a priority, determine whether the story can be broken down, and move the pending work as a new story into the product backlog.
- Do we want to take a different approach?
- What work is remaining?
- Can we break it down further to reduce risk?
Validate committed stories against available team capacity. While using velocity to determine what you are committing, create subtasks for each story and estimate them by using hours. Total hours estimated must match the capacity of the team for the given sprint.
Tips for better planning
Apply the following best practices to reduce or avoid spillovers:
- Always have a sprint goal. Undoubtedly, the most common mistake in sprint planning is misunderstanding the purpose of the meeting. Two takeaways from a sprint planning meeting: A sprint goal and a sprint backlog.
- Use story points for your sprint planning. After estimating stories by using story points, estimate tasks under each story by using hours. Track the team's capacity (consider leave, training, etc.). Tasks assigned to individuals should be based on the available hours.
- Leave space for unplanned work. Leave room in your sprint plan for the tasks the team hasn’t thought of. Leave room for the tasks they have thought of, but that space might get bigger. How much room? Take a guess. In the next sprint, adjust that guess up or down and iterate to about the right amount over several sprints.
- Increase time spent on sprint planning. Another mistake Scrum Teams make is to spend insufficient time on planning (mostly, time is fixed for planning). There is no fixed time. Scrum experts suggest a four-hour sprint planning session for a two-week long sprint. Poor planning may result in spillovers. Evaluate the time required based on the complexity or size of what you are trying to achieve.