Tips to Avoid Spillovers in a Sprint

What are Spillovers?

In Scrum, if all the Sprint Backlog items are not completed by the end of the sprint, the incomplete items are moved back to the Product Backlog and are referred to as spillovers. These spillover items will be taken up in a future sprint. Having spillovers means the development team could not complete the Product Backlog items they committed to during Sprint Planning. This situation is undesirable for the team. The Scrum team strives to avoid spillovers as much as possible, and as the team matures, the development team becomes better at forecasting effort, thus avoiding spillovers.

The following are some of the main reasons for spillovers in a sprint:

• Underestimation of effort
• Overestimation of team capacity
• Unexpected extra work or blockers
• Lack of coordination within the team
• Lack of focus
• Taking up unclear Product Backlog items in the sprint, and so on.

Let us now look at how spillovers can be avoided.

Do Effective Capacity Planning

Capacity planning is an assessment done by the team during Sprint Planning to determine how many story points the team can take up in a particular sprint. For those unfamiliar with story points, they are a unit of measure for the effort required to complete a feature using relative sizing. If a team is not able to reasonably assess their capacity, it is likely that they will either over-commit or under-commit on the features they will complete in the sprint.

In order to effectively plan the team’s capacity, the following factors need to be considered:

• Number of working days in the sprint
• Any planned leaves or vacations for team members
• Availability of shared resources
• Hours to be dedicated for backlog refinement and other events like Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective
• Average velocity of previous sprints

Capacity of the team is calculated in story points. It is common practice to calculate the capacity of a team by projecting the man hours or days available in this sprint and deriving a proportionate story point based on the team’s average velocity and average man hours or days spent in the previous sprint. The formula would be:

Capacity = Projected man hours for this sprint * (Average velocity of the team / Average man hours spent in the previous sprint)

Take Up Only Thoroughly Refined Product Backlog Items in a Sprint

Developers should only take up Product Backlog items in a sprint if they are clear and all the necessary information required for their implementation is available. Backlog items created by the Product Owner become mature only when they are explained to developers and discussed during the refinement process. This brings the required clarity, enabling the development team to provide an effort estimate.

To ensure only the right backlog items are brought up in Sprint Planning, the team often agrees on a Definition of Ready (DOR), which sets the criteria that need to be fulfilled for a Product Backlog item to be taken up in a sprint. Below are a few examples of what can be included in the Definition of Ready:

• The backlog item is explained by the Product Owner to the development team and all questions are answered
• The Product Backlog item has acceptance criteria based on which the feature can be validated
• The Product Backlog item is estimated in story points
• The estimate of the backlog item does not exceed 8 story points. If it exceeds, it is subdivided into smaller stories or backlog items
• There is no blocker dependency

Effectively Plan the Work During Sprint Planning

Sprint Planning consists of two main activities:

1. Determining What to Do: Deciding which Product Backlog items will be taken up in the sprint.
2. Determining How to Do: Analyzing the backlog items and coming up with a plan on how to get them done.

The first two points we discussed take care of the "What to Do" part, but the "How to Do" part is not given the importance it deserves by many teams, which could lead to spillovers in the sprint. Planning involves two main functions:

1. Analyzing the backlog item and dividing it into smaller tasks
2. Estimating the effort required for each task in hours

Here are some points to consider while creating tasks:

• Try to divide the backlog items into as small tasks as possible, never exceeding one day of effort
• If multiple developers can work on a task, try to create separate tasks for each person, rather than having multiple people work on a single task
• Look into the "Definition of Done" for the backlog item and create a task for each point in the DoD in addition to the regular development task (e.g., code review, automated tests, performance testing, Product Owner review, etc.)

Proper planning forces the developer to think about the practical aspects of requirements that may be overlooked during the refinement process. At this stage, if the developer feels that the initial assessment of effort was not sufficient, there is an opportunity to negotiate with the Product Owner and adjust the plan. This will reduce the chances of underestimation and uncertainties, helping to avoid spillovers in the sprint.

Learn from Past Mistakes

It is normal to have spillovers in the early days of Scrum. However, after a few sprints, the team learns from their mistakes and matures, which enables them to avoid spillovers in future sprints. Inspection and adaptation are two of the three pillars of the Scrum framework, and the Sprint Retrospective is a Scrum event specifically used for inspecting and adapting processes.

If spillovers occur frequently, they should be taken up in the Retrospective meeting, where the root causes of the spillovers can be analyzed. This helps identify and fix issues related to processes that contribute to spillovers.

Reduce Work in Progress

Spillovers happen when the team does not have enough time to complete all the agreed backlog items. The reason for this shortage of time could vary, but if such situations arise, the focus should be on reducing the number of Product Backlog items the team is working on in parallel.

Let’s try to understand this with an example. Assume that in a sprint, the team has committed to 5 backlog items totaling 25 story points (for simplicity, let’s assume each backlog item is estimated at 5 points). The team starts working on all items simultaneously. As the sprint nears its end, the team realizes their actual capacity is only 20 story points. Since work on all backlog items was happening in parallel, by the end of the sprint, none of the items is completed. The team's velocity for the sprint will be 0 as a result.

Now let’s assume the team decides to cap the maximum number of backlog items worked on in parallel to 3. In this case, the team completes the first set of 3 backlog items (15 story points), but does not complete the next 2. Thus, the team's velocity will be 15 instead of 0.

If the team focuses all its effort on one backlog item at a time, they will complete 4 backlog items with only one spillover. This example shows how reducing work in progress can reduce spillovers, even if all other factors are the same. In the real world, it may not be efficient for the entire team to work on just one backlog item at a time, so the team will need to find an optimal level where efficiency is not compromised, but work in progress is reduced.

Effectively Use the Process of Inspect and Adapt in Daily Scrum

The Daily Scrum is an important Scrum event where, on a daily basis, the team inspects and adapts their progress toward the Scrum goal and takes corrective action if necessary. Many times, the Daily Scrum is conducted mechanically without understanding its core principles. This can lead to the team losing focus on the bigger picture, resulting in spillovers.

Spillovers can be avoided if deviations are detected early in the sprint and corrective actions are taken. Here are some good practices to follow during the Daily Scrum to avoid spillovers:

• Keep the Burndown Chart visible to all team members during the Daily Scrum, review it, and make it a discussion point
• Scrum Masters should ensure all impediments are addressed and that the team members are not stuck
• Team members should be transparent and ask for help if needed
• Stay focused on the Sprint Goal

Conclusion

Avoiding spillovers in a sprint is essential, and we have discussed several tips to help achieve this. However, this does not mean that the team should try to game the process to mark Sprint Backlog items as complete. The Scrum team should strive to close all the committed backlog items in a sprint, but the Product Backlog items should be complete in their true sense and should deliver value to their users.