Unfinished Stories in Agile and Tasks in an Agile Sprint

In my role as a scrum master, the last week of the sprint and in particular the last day always makes me nervous. Do you also face something like this? Why do you think you and I are put into this situation… We are after all the process owners in the organization aren't we? Well, this phenomenon is not new and I am sure a lot of peers including the most experienced one feel jittery and this feeling is a result of spillover in Agile i.e. stories committed by the team but not completed for one or more reasons. In this article today, let us try to clear the air around this peculiar yet contentious Agile situation and dig into the causes, corresponding tools, techniques, and best practices to deal with them. 

Take the Agile certification training from KnowledgeHut to learn the best practices, avoid common pitfalls or antipatterns in your agile transformations, and drive positive changes in your workplace.

What are incomplete stories and tasks in a sprint?

By definition, spillover in agile i.e. incomplete stories and tasks are those items that were committed as a part of the sprint backlog but could not be completed or did not meet the definition of done towards the end of the sprint? These unfinished work items were analyzed, estimated, and plugged into the sprint backlog with the expectation of being completed; however, they may have checked all but one or none of the definitions of done criteria, causing them to become sprint spillovers or leftovers. Although, the way spillover work items are treated largely differ, in general, such items will have to be reassessed for estimations, priority, and challenges/dependencies to establish efforts and plan for their completion. Irrespective of their cause or scenario, these often cause butterflies in the stomach for everyone on the team making them often contentious. 

Importance of Addressing Incompleteness

Agile development involves iterative and short cycles to cater to business requirements mapped to be completed over sprints and these are backed by customer collaboration and feedback to ensure they align with what is expected. In such scenarios, teams that fail to maintain a constant pace end up getting off-track from the planned roadmap and delivery goals. To avoid the cascading effect of such situations, teams need to plan thoroughly to establish clear guidelines on how best they can support team members to complete how much they take and how they get around issues. Be it any framework, agile team members need to be self-organizing and cross-functional to be able to pick up and complete committed items irrespective of their roles and complete the sprint goal as a team. Learn how to motivate teams and keep them engaged towards the fulfillment of sprint goals by building a strong foundation with KnowledgeHut Agile certification training.

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!

Best Practices

Incomplete stories tasks in an agile sprint are an agile antipattern yet common for teams who fail to estimate, prioritize, or catch up on work items thoroughly during the sprint. Though it may look like that, they necessarily do not signal poor performance of the team. Here are some key best practices that will help agile teams overcome such tricky situations: 

• Start with the end in mind - Team members picking up work items must be clear on how they will end the item before starting on it. 
• Limit work in process items - This is one of the most beautiful qualities the Kanban framework has blessed agile teams with. In my experience, having work-in-process limits i.e. finishing existing items before starting new ones, clearly sets the stage for a thorough and well-completed sprint. 
• Have a strict definition of ready - A clear definition of ready is a signal for the team that the story does not have too many unknowns/challenges and can be committed to completion for the sprint thereby minimizing chances of spillovers. 
• Have the required processes well documented - Contrary to what most of you may think, Agile involves more documentation of required processes as the time to fall and get back on track is much less and teams need to have an aggressively documented approach to deployments, sprint activities, etc. 
• Ensure balance of features and tech debts - Teams who have a well-balanced backlog with features as well as tech debts tend to have fewer technological challenges or impediments thereby reducing spillover rates and contributing to higher delivery. 
• Make retrospectives interactive and intriguing - Having focused and empathetic retrospective discussions helps team members open up about challenges they encounter during the sprint and gives learnings to the team to improve their ways of working as well as processes. 
• Review pain points and address challenges - Once retrospective learnings are gained, it is time to put them into action and fine-tune the processes to address the challenges encountered by teams to minimize delays, idle times, or challenges resulting in unfinished work at the sprint end. 

Though the above may not be an exhaustive list of best practices, they set the ground for any agile team to embrace the changes and move at a constant pace toward delivery. 

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.