Have you ever encountered a situation such as the above? I am sure you have and I am sure that you experience this often. So, how do you deal with it? Do the managers in your company make a big issue out of it? Is it a situation probed intensely by the product owner and even the Scrum Master who is the team’s protector? You need not worry. Below is a discussion on incomplete sprints, better known as ‘Spillovers’, and on how to best deal with them, user stories examples, etc.
Spillovers & DoD – The definition
Simply put, a spillover is a backlog item that has 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 is applicable to any user story. For example, a team may decide that the DoD for a user story is for it to be elicited, groomed, analyzed, designed, UI / UX designed, coded, unit tested, functionality tested, integrated and regression tested.
Any story not ticking all these boxes may be marked as not done. Well, not always!! The team may decide that some of these criteria are not applicable to certain stories during sprint planning and those should be evaluated accordingly.
Trouble with Spillovers?
Spillovers normally surface during Sprint Demo & Retrospective meetings and often give trouble to Scrum team members and product owners during sprint planning. It is the responsibility of the PO to mark a user story as done by going through the DoD criteria. Then only should the story be moved to the ‘Done’ column on your JIRA board? Sometimes the POs end up scratching their heads as a result of poorly defined DoDs or just pass stories on to the Done state just ensure progress. Similarly, during planning teams end up spending a lot of time discussing these spillover stories and doing extensive planning for these unfinished user stories.
Spillovers are common phenomena for any agile team. But it is important to analyze the root causes for these spillovers if this happens often.
Common Reasons for Spillovers
Below are some common root causes for unfinished work-
1. Problems with DoD – The DoD was not accurately defined, and you find that out later in the sprint. This results in the argument around marking the story as ‘done’.
2. Overestimation of work for the sprint – The team becomes over-ambitious and commits too much more than they can handle.
3. Larger chunks of work eat up the time of other stories – This is actually not a big issue. Story point estimation is a relative estimation and has no link to the time needed in hours. Hence, this overrun of time may happen often.
4. Unforeseen scenarios – There may be situations where a team member becomes unavailable due to sickness, other work commitments, or personal commitments. Other situations related to team members not being able to access code repositories due to various environmental elements may also cause delays.
5. Change in priorities – PO may decide to change the priority of stories mid-sprint or stories may even become a higher priority with technical limitations. As a result, stories may not be completed and may get spilled over to subsequent sprints.
Dealing with spillovers
So it is important to devise strategies on how to manage such unfinished work. Below are some recommendations on how to do so. Again, this is not rocket science but the application of some common sense to make things work.
- 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. It is important to note that the cause for most delays may be common and thus the team must understand the factors related to delivery delays to quickly move on to discuss other aspects important for project success.
- The team must discuss the future of the user story that got spilled over. The PO must decide whether the story is still on high priority or not.
If yes, then simply move the story forward to the next sprint. You have already decomposed the story to the most granular level during grooming and it is just a matter of getting it done. Again, if the story was done partially it is important for the team to discuss the amount of work remaining to mark the story as done. This analysis may actually result in the creation of a new user story with new acceptance criteria, a completely new DoD, and a brand-new estimation.
If not on priority, simply move the story to the bottom of the product backlog. The story will get evaluated for priority during backlog grooming and be moved up or down the backlog as relevant.
- I previously wrote an article on capacity planning for agile teams. It makes sense for the Scrum Master to understand the availability of the team for the entire duration of the sprint and plan the amount of work that can be taken up accordingly. For more information on capacity planning and how it may help avoid spillovers.
- Some more logical thing to do is to dedicate more time to planning. This may be done by defining a proper goal for the sprint and ensuring that all user stories are aligned with this particular sprint goal. The scrum team may also set aside some buffer time for unplanned work which will give the team some breathing space just in case a story runs for more than planned.
Elevate your career with our PMP classes online and master the art of project management. Learn from industry experts and achieve new heights of success!
Conclusion
So in conclusion, spillovers are to be managed properly. You may never be able to completely eliminate it from your projects. But with proper management and planning, you can reduce the number of times it may occur and be able to reduce its impact.
Upcoming Agile Management Batches & Dates
| Name | Date | Fee | Know more |
|---|
Offer