Get certified - Transform your world of work today

Close

How to Avoid Spillovers

Effective planning is the key

26 June 2017


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.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (2 ratings)

Comments

Tim Baffa, CSM, 6/26/2017 12:01:13 PM
Good observations and suggestions around sprint carryover (spillover).

While I believe it is beneficial for teams to identify the tasks and subtasks for a PBI, I personally feel it is wasteful for teams to also provide a time estimate for such tasks/subtasks.

Will each Development Team member forecast task completion in the same time frame? If not (due to skill, experience, knowledge, etc.), then are we suggesting that the team participate in a consensus estimation exercise for each task/subtask?

If the team has already provided a relative story point estimate for the PBI, and confirmed that relative estimate once they've identified the known tasks for it, what more is needed?

I do think that an hours-based team capacity metric is very important, and I review that along with the team's known velocity to give the team as much information as possible so that they can made a good decision about what work they can forecast for the next sprint.
Julian Bayer, CSM, 6/29/2017 9:50:40 AM
I concur with Tim. Our team abandoned time-based estimation of subtasks and so far we have yet to notice any negative impact.

As for the hours-based team capacity, I use Scrum Inc.'s "Yesterday's Weather" spread sheet, which quite honestly does nothing else but adjust your projected velocity by time-based capacity. While it may not always be accurate, it works well enough.

You can find the spreadsheet at https://www.scruminc.com/yesterdays-weather/
Niroshan Madampitige, CSP,CSM, 8/11/2017 12:19:09 AM
@Tim, @Julian, Thanks much for your comments, we may discuss this further.
Niroshan Madampitige, CSP,CSM, 8/23/2017 6:58:38 AM
@Julian, @Time, I agree velocity based commitments work, but, my experience says, there is around 20% uncertainty around velocity. Yes, we shall use velocity predictions but then, to validate if what we have committed is what we can do, i recommend creating sub tasks and asking dev team to estimate the sub tasks. Now, the total hour should be closed to total availability of the developers.

Here is the same argument made by Mike Cohn.
"Consider a team in a velocity-driven sprint planning meeting. They’ve selected a set of stories equal to their average velocity. They then ask themselves if that set of stories feels like the right amount of work. (As described, in the post on velocity-driven sprint planning they may also identify tasks and estimate those tasks as an aid in answering that.)" - Mike Cohn

https://www.mountaingoatsoftware.com/blog/why-i-prefer-commitment-driven-sprint-planning

BTW, Thanks much for "Yesterday's Weather" link - that's useful

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe