Remember our Gapstars Scrum Cheat Sheet for Beginners? Well, you may want to get that out again and keep it within reach, because today we’ll take a deeper dive into a specific scrum phenomenon called spillovers. If you’ve ever wondered what a spillover is, it’s a backlog item that doesn’t meet the Definition of Done (DoD). Basically it’s unfinished work, to put it in ordinary human language. 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 occasionally have some unfinished work. However, if this happens often, I suggest that you evaluate the root causes and find ways to minimize or even avoid the spillovers altogether. Here are 8 recommendations to help control the situation.
Causes of unfinished work
Before we take a closer look at some of the ways to avoid spillovers though, it’s good to know what the potential causes of this unfinished work can be. I’ve put together a (non-exhaustive) sampling for you:
- You overestimated what you could complete in one 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 figured that out too late.
- Consequently, when you’re at the sprint end, you are not able to make it to “Done.”
Managing unfinished work
Right, enough about what causes the problem, onto the solutions now. First off, how do you best manage unfinished work? If you find yourself faced with spillovers, the only thing left to do is try and deal with the situation as efficiently as possible. Here are a few recommendations to control and organize the uncompleted work:
Understand the root cause and know 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 remains a priority, don’t spend time breaking it down any further. The team is already 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 anymore, 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 to, create subtasks for each story and estimate them by using hours. The grand total of estimated hours must match the capacity of the team for the given sprint.
Tips for better planning
Of course, ideally you want to completely avoid spillovers. Rather than having to do damage control afterwards, you’d spend your time on making sure there’s no unfinished work in the first place. Try to apply the following best practices to reduce – or even totally avoid – spillovers from happening:
Always have a clear sprint goal. Undoubtedly, the most common mistake in sprint planning is misunderstanding the purpose of the meeting. The two main takeaways from a sprint planning meeting are: A sprint goal and a sprint backlog.
Use story points for your sprint planning. Once you’ve estimated stories by using story points, estimate tasks under each story by using hours. Track the team’s actual 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 for which that space might get bigger. How much room? Take a guess. In the next sprint, adjust that guess upwards or downwards and reiterate to approximately the right amount over several sprints.
Increase the time spent on sprint planning. Another common mistake Scrum Teams make is to spend insufficient time on planning (mostly, the time available for planning is set beforehand). There is no such thing as a set time. Scrum experts suggest a four-hour sprint planning session for a two-week long sprint. Poor planning may (will) result in spillovers. Evaluate the time required based on the complexity or size of what you are trying to achieve.
Say goodbye to spillovers
So there you have it, 8 recommendations on how to reduce or avoid spillovers. I’m not saying they’re an absolute guarantee for a spillover-free scrum life, but it’s definitely a solid first step. If you make sure you have a clear sprint goal, you use story points for your sprint planning and – perhaps most importantly – build in space for unplanned work and extra time for planning, it should get you a long way. Time to get started!