Get certified - Transform your world of work today

Close

Sprint Backlog Spillover

Possible causes and ways to control it

3 October 2017


The sprint backlog is a subset of the product backlog that the Scrum Team commits for an iteration, after careful consideration and deliberation, during sprint planning. But spillover (the inability to meet the "Done" criteria for all stories) continues to be a reality. With a forming team, the probability of spillover is even higher. It is absolutely critical to draw patterns from the spillover to identify the root causes and apply the learnings to subsequent sprints to avoid its reoccurrence.
 

Patterns that lead to spillover

You might observe the following patterns that typically lead to spillover of the sprint backlog.

Incomplete user stories

An overly committed sprint backlog that may have been planned with insufficient buffers is more likely to slip. User stories that are not thoroughly scoped, dependencies that are not factored in, stories written with only development activities in mind, or stories written without considering the associated user value are some of the other common reasons for spillover. The team that picks up such a backlog tends to spend unproductive time on rescoping stories and sorting dependencies.
 

Lack of communication and collaboration

Improper communication or not being actively engaged in daily stand-ups also leads to spillover. Often, development and testing engineers do not communicate clearly, leading to resources assuming expectations and commitments — for example, testing may assume that development will signal when to start.

To expedite and remove redundancies, the developers, on their own, often provide builds to the tester without unit testing, which creates a scenario in which the testing effort is wasted on basic code issues. Multiple "private" build exchanges between the developer and tester constitute another reason that increases the turnaround time, and eventually the stories spill. This is typical of a group of individuals who work on a team but without the spirit of collaboration.
 

Inefficient Definition of Done

To make the Definition of Done (DoD) exhaustive, the organization may set up a complicated set of Done criteria. To meet this DoD, the team must identify too many story tasks, and the usual sprint duration might fall short of accommodating all of them.

Some other inefficiencies include traditional testing approaches, planning automation toward the end of sprint, and generating builds with outdated setup (which is time-consuming).
 

Parallel versus sequential: The right mix

Rather than estimating effort required to work on prioritized stories sequentially, Scrum Teams start on all stories committed in parallel. For example, an eight-member team starts on the sprint backlog of four stories simultaneously, with two engineers per story. If any unanticipated event occurs whereby the top priority story requires more man hours, without reshuffling the resources, the team can’t complete the top stories.
 

Spillover: Opportunity for improvement

In some cases, user stories will spill over from one sprint to another. Here a several tips that can mitigate spillover.
  • Committing to the next sprint should be done carefully, considering how much effort will be spent to bridge the gap. The product owner and technical leaders must thoroughly analyze spilled-over stories to identify contributing factors and help the Scrum Team address them.
  • Writing user stories with well-defined scope and acceptance criteria is the best way to avoid spillover; if the user story complexity is medium but the line of code required is huge, having the correct acceptance criteria will define the right scope of work. The product owner and subject matter experts should invest sufficient time in breaking down epics into user stories.
  • Avoiding redundant testing and identifying the right amount of automation can be crucial to efficiency and help to reduce future occurrence of spillover.
  • Meeting the DoD set for any organization doesn’t mean that each user story needs to meet the DoD. It’s up to the Scrum Team to determine how they will leverage the Done criteria without creating any technical debt or compromising on quality.
  • Developing focused communication and collaboration strategies — like one-on-one discussions or team discussion platforms — may avoid slippage. Sometimes developers just linger around a story for the entire sprint without seeking help from fellow team members.
  • Religiously syncing up among the Scrum Team members and having a sense of urgency and commitment toward their own decision will be helpful.
  • Periodically checking the Scrum Team task board also helps to identify possible spillovers. If a certain task sits on the same status, there might be some obstacle hiding behind it.
It’s OK to have spillover when there is an unavoidable situation that cannot be anticipated, even after proper planning and discussion. But frequent reoccurrence of spillovers is a pattern for concern. The ScrumMaster, along with concerned stakeholders, plays a significant role to make the necessary adjustments. It is important to have meaningful retrospectives to learn and identify action items. Continuous implementation of those action items and periodic reviews will be helpful to avoid any future spillovers.
 

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.3 (3 ratings)

Comments

Ashish Agrawal, CSM, 10/5/2017 8:09:01 AM
Great Article Anuka :)

Sprint spillover, should be fine, if that is due to unavoidable reason, but often its seen that PO does not groom story very well & that leads to discovery of "extra work" leads to spillover, so I feel PO plays a very important role to make his/her team successful while "refining" stories well in advance, show them to team during look ahead meeting & keep sufficient time to answer questions from team.

Often the case POs are too busy & Spillover "comes" to team or scrum master to manage, so regular retrospective feedback to PO does help in avoiding spillovers are making scrum team successful.

-Ashish
Anurag Agarwal, CSP,CSM, 10/10/2017 8:13:03 PM
Well thought article Anuka.

One of the reasons for user stories spilling over which I observe is inefficient sprint planning. If teams get together during sprint planning and do an efficient task breakdown, it brings out many of the hidden aspects which might have been overlooked earlier during backlog grooming. These can be either dependencies or scope of work which was overlooked. A User story defines the "What" is the expected outcome of it. During Sprint Planning meeting, team discusses "How" the scope will be achieved and what work needs to be done to achieve it. When they discuss how they would achieve the sprint goals, scope of the "work" becomes clearer. This could lead to identification of dependencies or hidden or missed scope of work. If the scope of work in user story cannot be achieved during the sprint, the team can approach the PO to breakdown the scope of the user story further into smaller user stories. There is a possibility of uncovering a hidden risk during the sprint planning discussion. Having a Definition of Ready (DoR) could ensure that User Story is complete when accepting it to be worked upon during the Sprint.

Task breakdown exercise sets the path for the team to take during the sprint. Detailed task breakdown helps team members identify individual activities and align their tasks to meet the sprint goal. Collaboration among the team members comes as an added advantage of task breakdown exercise. This helps the team members monitor their progress during the Daily Scrum and take action based on the risk seen. Detailed task breakdown also helps team understand if they would be able to complete the user story in a sprint. Based on this understanding they can commit the user story for the sprint.

Daily Scrum meeting is a discussion which helps team to look at their activities for that particular day and how it would help them achieve their sprint goals. Effective Daily Scrum meetings help team know well in advance if a particular user story would spillover and PO can either re-prioritize the user stories or set the customer expectations accordingly.

Its acceptable to spillover User Stories to the next Sprint due to unanticipated activity which comes up. In such cases it would be prudent to discuss with the PO and allow the low priority or low impacting user story to spillover and reduce the release risk. Such spillovers are required to be retrospected. There are cases where unanticipated activity could have been planned and prioritized for the sprint.

Organizational environment and organizational practices brings in the sense of urgency in the team members and they strive to complete the user story in a sprint.
Anuka Bindhani, CSM, 10/11/2017 7:49:53 PM
Ashish Agrawal : I agree on the part that refinement of stories with well scoping and clearer acceptance criteria is a must, might be we as scrum master act as enablers to follow definition of ready when an story is up for team to pick up in planning.
Anuka Bindhani, CSM, 10/11/2017 7:56:48 PM
Thanks Anurag for bringing out the importance of task breakdown and close collaboration among scrum team members, studying the pattern for taking preventive action and strive upon the commitment should be key.
Anuka Bindhani, CSM, 10/11/2017 7:56:50 PM
Ashish Agrawal : I agree on the part that refinement of stories with well scoping and clearer acceptance criteria is a must, might be we as scrum master act as enablers to follow definition of ready when an story is up for team to pick up in planning.
Anuka Bindhani, CSM, 10/11/2017 7:56:51 PM
Thanks Anurag for bringing out the importance of task breakdown and close collaboration among scrum team members, studying the pattern for taking preventive action and strive upon the commitment should be key.
Anuka Bindhani, CSM, 10/11/2017 7:56:51 PM
Thanks Anurag for bringing out the importance of task breakdown and close collaboration among scrum team members, studying the pattern for taking preventive action and strive upon the commitment should be key.
Sureshchandra Sharma, CSM,CSPO, 10/15/2017 6:04:57 PM
Nice point Anuka. I had these issues too and I learned such issues were majorly due to technical stories where the PO participation was minimal or nil. So mainly the development lead or architect add's the stories details (e.g. batch jobs, or backend work, load testing etc.), and they often miss adding detail in timely manner or appropriate acceptance criteria for one or other reason.

My learning was even such stories also needs to be refined in a formal meeting with team even if "PO" is not required. Booking such formal meeting time helped to reduce spill over and improved Sprint planning.

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