How to Handle Stories That Aren't Completed in a Single Sprint

One of the most common questions new Scrum teams face is how to handle stories that were not completed in one Sprint and must be rolled into the next Sprint. While there is no universally-agreed-upon guidance for how to handle this, here is an approach that I've found that seems to work well for most teams.

Dealing with Stories That Roll Into the Next Sprint

Whenever your team finds an incomplete story at the end of the Sprint, simply roll that story, in its entirety, into the next Sprint. When this happens, no points should be awarded to the team, for partial completion of the story.

Furthermore, I recommend that teams do not re-estimate the remaining effort of the story in the next sprint. However, I do recommend that the team take this opportunity to reevaluate their estimate for the entire story. For example, to consider whether anything has been learned during the previous Sprint that would indicate that the story is more or less complex than the team previously thought. This is also an excellent chance to consider whether the team may now see a simpler, alternative approach that wasn't obvious before.

However, if the estimate for the story does change remember that the estimate should represent the complexity of the entire story, not just the portion that remains.

Seeing This in Action

To better understand how this approach works, let's look at an example. Imagine that your team began work on a story that was estimated at 8 points in Sprint 1. However, rather than completing the story in its entirety, your team only gets 70% of the way through the story before the Sprint ends and then must roll that story into Sprint 2.

At the end of Sprint 1, your team is awarded no points for the story in question, even though your team reports that the story is 70% complete. Instead, the story is rolled into Sprint 2 with the full 8 point value. Once the remaining 30% of the story is completed in Sprint 2, the team is awarded the full 8 points for completing the story.

Understanding the Benefits of This Approach

There are several benefits to this approach. One of the most important is that failing to award teams "partial credit" for work completed reinforces to your team their goal is to deliver value, not to simply stay busy. In most cases, a story that's 70% complete doesn't deliver 70% of that story's potential value; it delivers no value. As a result, it shouldn't yield any points for the team.

Now taking this approach is likely to upset your team, but arguably that's a good thing. One reason is that taking this approach will further focus your team on value delivered, rather than the effort expended. Another reason is that this approach will encourage your team to continue to break their work into smaller stories.

Smaller stories have a multitude of benefits over larger stories, such as less complexity and therefore less risk, but they also tend to be easier for your team to understand. But despite these benefits, some teams resist the shift towards smaller stories. However, feeling the pain first hand of losing a significant amount of points in a Sprint simply because a story is almost complete is an excellent way to incentivize your team to look for seams to break their largest stories into smaller stories which can be delivered in the space of an entire Sprint.

Seeing the Bigger Picture

When following this approach don't be surprised if you hear complaints from your stakeholders that carrying over so many points from Sprint to Sprint is likely to skew your team's velocity. For example, depressing your team's velocity in the first Sprint only to artificially inflate it in the next Sprint.

However, this is an excellent opportunity to shift the conversation with your stakeholders from focusing on your team's velocity at the individual Sprint level to instead thinking of your team's velocity in aggregate across several Sprints. Not only will this shift in thinking better equip your organization to plan for the long term, but the variations in velocity from Sprint to Sprint will better average out across multiple Sprints.

Moreover, just as with your team, this is also an excellent opportunity to begin shifting your stakeholders' attention away from points closed and towards value delivered.

Seizing the Opportunity to Reevaluate Priorities

As a final note, I want to emphasize that no story should ever simply be rolled into the next Sprint without the Product Owner first taking a moment to consider whether continuing to invest in that story is even still the best use of the team's time.

A Product Owner is accountable for ensuring that the organization's investment in the team is made so in a way that will yield the most significant return for that organization. To this end, when planning the coming Sprint, the Product Owner should be considering whether each story selected is truly the highest value item on which the team should be working.

This means that even though a story might have been considered the best use of the team's time at the beginning of the last Sprint, that doesn't necessarily mean that will remain true in the next Sprint. Perhaps higher value work has emerged since the previous Sprint was planned or perhaps there has been a development in the marketplace which has deemed that story no longer necessary.

Or, perhaps the story in question is still important to the organization, but upon closer inspection, the Product Owner realizes that the work the team has done thus far is enough to add the value needed. As a result, the remaining work is simply no longer necessary or at least can be deferred.

Whatever the outcome, the Product Owner should always take the opportunity to evaluate whether continuing to invest in an in-progress story is truly the best use of the team's time or if there is now more impactful work that the team should be pursuing. In either case, the key is to avoid falling into the fallacy of sunken cost and simply continuing to pursue a story to completion simply because work on that story has already begun.

Continuously Inspecting and Adapting

Remember that every Sprint is an opportunity to inspect and adapt the work the team is pursuing. Part of that process is continuously inspecting the work that the team is currently tackling and adapting that work if it’s deemed to no longer be the best use of their time.

By regularly re-evaluating the stories the team is rolling from Sprint to Sprint and shifting the focus from "staying busy" to actually delivering value, the entire team can help to ensure that they are in a position to deliver the most value for their users as well as their organization.