Unfinished stories in Scrum – the easy way to handle sprint spillover

One of the most frequent questions I get from teams new to Scrum is how to deal with unfinished stories after the sprint. More often than not, my recommendation surprises the teams. It is very simple and often seems counterintuitive to them. I believe that many overthink this topic. They tend to come up with the wildest ideas for dealing with sprint spillover. This is often caused by a misunderstanding of story points.

Today I’ll share my advice on dealing with unfinished user stories, discuss story points in general, and finally suggest three practical tactics if you are constantly dealing with sprint spillover.

Email address:

Leave this field empty if you're human:

Don’t put effort into dealing with unfinished stories

How to deal with unfinished stories in a sprint? My answer is simple: do nothing. Just finish them in the next sprint. As long as it happens only occasionally there is no need for further action. Simply ask the team to take into account the incomplete stories when planning the next sprint. That is perfectly sufficient.

Some teams re-estimate the unfinished stories, create new stories for the remaining work, or use any variety of fields in Jira to document leftover work. I don’t recommend these approaches. They are extra effort without any real benefits. 

Why I don’t recommend changing estimates

I have never heard a good explanation why it makes sense to re-estimate incomplete user stories. I have come to the conclusion that teams do this because they want to capture the exact amount completed each sprint, presumably for planning purposes. Changing estimates actually hurts more than it helps here. 

Forecasting the next sprints is anyway an exercise in telling the future. Product development is inherently uncertain. There is no shame in not being able to predict the future accurately. Nevertheless, story points or any other form of estimation do have a place in this context.

Velocity, the average number of completed story points per sprint, is useful in giving rough estimations as to what will be completed by when. However, to use velocity the planned and completed story points do not need to be the same in any given sprint. It evens out over time. The average accounts for the team not finishing all stories one sprint and over delivering in the next one. That is sufficient for near to mid-term planning. Changing the estimates of incomplete stories is unnecessary and messes up the average velocity more than it helps.

A quick reminder what story points are for

Much of the obsession around estimating the leftover work stems – at least in my mind – from misunderstanding what story points are actually for. They are relative measures for the effort required for a product increment. The subjective number takes into account the time, complexity, and uncertainty around the product improvement. 

Story points are not a scientific, universal measure. They are not – and don’t need to be – “correct”.

Estimating a user story serves as a basis for discussion. Differences in estimates create transparency around the differences in understanding of the story’s scope. This quality gate is probably the most valuable aspect of estimations.

(For additional information, the Paint the Room game is an excellent demonstration of how story points work.)

What to do about frequent spillover 

Back to the topic at hand of dealing with sprint spillover. As mentioned above, I generally don’t recommend any specific action – as long as you are still able to increase the product value every sprint. However, frequent spillovers can indicate that this is not happening.

It may be a symptom of some underlying problem. Most likely the product increments are not defined well, the team has too many dependencies and has to wait for other teams, or the internal process is off. 

To address this, you need to analyze the organizational set-up and try to minimize external dependencies. You also need to ensure that you are not doing waterfall disguised as Scrum within the team. These two organizational solutions often require time and effort.

But there are also things you can immediately put into practice. Here are three suggestions:

• Underplan
• Make smaller increments
• Stop using story points in planning (or overall)

Underplan

Teams often overcommit because they feel they need to or because of their own aspirations. Sometimes you need to save the team from itself. It can help to underplan the sprint. 

Conduct the planning as usual, then remove one or two stories before starting the sprint. In case the team finishes all stories before the sprint ends they can always pull in additional user stories. Also, a few days of idle time is a great opportunity to reduce technical debt. 

Underplanning for a few sprints can be a great way to get back to a rhythm. Be wary of Parkinson’s law, though. 

I have also had success with switching to a Kanban approach for a limited time until the board is empty. Don’t start a new sprint after ending the last one. Instead, finish all in-progress items, possibly pulling in small increments from the backlog in case people are idle. This leads to a clean board and a fresh start. Then, do a regular sprint planning, underplan a few sprints, and regain your rhythm. 

Make smaller increments

Frequent unfinished stories within a sprint can signal that the product increments are not defined well.They are likely not sliced correctly and end up too large. 

In the refinement process it’s important to always answer the question “Can we make this story smaller and still deliver value to our users?” We sometimes explicitly add this to our definition of ready. 

It’s also possible to resize the story during the sprint. If the team realizes they cannot fulfill all the desired functionality until the sprint ends, they can discuss with the PO to reduce the scope. 

Whether before or during the sprint, the important thing is to slice the story horizontally by removing some functionality but still delivering value to the end users. Do not split it vertically by separating e.g. development and testing.

Stop using story points in planning (or overall)

Many Scrum Masters calculate the number of story points the team completed in the last few sprints, then account for holidays, vacations, self dev time, buffer, meetings, and whatever else might come up. After spending significant time and energy they might then come to the conclusion that they have 18,93 story points available for the next sprint. 

This is then the golden number they use in the planning. They don’t allow going over that number, they also don’t allow for less.

While the number might be a helpful reference, it is not worth the effort. It might make more sense to not use the story points in planning. Instead, having a prioritized list of refined backlog items and asking the team how far down the list they think they can go is often the better solution. The engineers’ gut feeling is often right.

You could also stop using story points altogether. If the team is able to ensure that all stories are reliable the smallest deliverable piece, the increments will end up being in effort. If the team has a good discussion culture and is able to properly refine stories without the quality gate of estimations, then there is no need to use them. Instead of the velocity you can then use the number of completed items per sprint to forecast in the short- to midterm.

A word of caution here. Many are not able to consistently get to the smallest deliverable piece. Thus, the more mature the team the easier it is to discard story points altogether.

Keep it simple

Unfinished user stories in Scrum are not a big deal as long as they happen only occasionally and the team is still able to deliver value to the customers every sprint.

However, unfinished sprints becoming the norm can indicate some underlying issues that need to be addressed. The team can try to underplan, make smaller increments, or stop using story points to improve their sprint performance and reduce spillover. 

The most important thing is to have good communication and collaboration within the team to ensure that the user stories are well-defined, prioritized, and sliced. By doing so, the team can avoid frustration, increase transparency, and deliver better products.

Coverphoto by vectorjuice on Freepik