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.
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.
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.
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.
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.
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.
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!
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.