You get to the end of a sprint and find that you still have user stories that were not completed. Why does this happen? How should you deal with it? And how do you prevent it from happening again? This article addresses all of these questions.

Why do Sprints end with Incomplete User Stories?

As a Scrum Master, you’re bound to come across the situation where you reach the end of a sprint and there are still one or more user stories that were not completed. You’ll know that this is not the best of outcomes because:

• The team have failed to complete the user stories that they forecast they would complete during the sprint planning session.
• The team velocity figure will be affected and thus affect future planning.

Understanding why the team did not complete all of the stories is vitally important to the team and must be covered during the sprint retrospective meeting. What you really need to deduce is whether this was a one-off anomaly or an emerging trend.

An anomaly is usually an unforeseen event. Examples of anomalies include:

• A team member off sick for half the sprint.
• A single User Story is found to be far bigger than initially thought.

An emerging trend is usually indicated by a repetition of avoidable problems. Examples include:

• Poor estimating
• Over-optimism
• Poor coding quality

Emerging trends need to be addressed otherwise they will affect all future sprints. Anomalies usually just need to be understood and the unfinished user stories dealt with.

How do you Deal with Inaccurately Forecast Sprints?

Surprisingly, the Scrum Guide gives no clear direction on how you should deal with inaccurately forecast sprints and so the approach you take is very much up to you. Advice offered on the Internet varies but here’s the approach I take:

[quote style=”boxed”]Irrespective of how much work has been done on the unfinished User Story, put it back in the Product Backlog so that the Product Owner can decide whether to enter it for the next Sprint or re-prioritise it.[/quote]

It sounds simple and it is. But, here’s the contentious bit. Leave the User Story estimate as-is.

Some will argue that this is wrong. They propose that you should instead break the unfinished user story in two. One for the work that has been done, and one for the work that is to be done. The argument goes that this will preserve the team’s velocity. I have a number of problems with this though:

• A User Story should provide business value. By breaking an unfinished user story into two, you’ve produced two stories that, in isolation, provide no business value
• You’ll be arbitrarily dividing Story Points between two new User Stories so they’re no longer estimates
• Because the newly formed User Story has no business value, the Product Owner cannot prioritise it.

Also, consider whether a temporary blip in the team’s velocity is that big an issue. We use velocity to help us decide how many User Stories we should consider for the next Sprint and to produce a product roadmap. If we know that a Sprint’s velocity is anomalous, we can treat it as such and discard that value in future planning and predictions.

But in any case, let’s look at an example:

Scrum Team Alpha has a velocity of 17. For Sprint 4, they take on 4 stories totalling 17 Story Points. Three stories are completed but one of them, originally sized at 8 Story Points, is not finished come the end of the Sprint.

The new velocity of the team is therefore the sum of the velocity of the three prior sprints plus the current sprint, divided by four. For the sake of our example, that’s 15 + 17 + 19 + 9 = 60 / 4 = 15.

At the next Sprint Planning session then, we should use the new velocity as a guide to how much work we will forecast to complete in the next Sprint. Again, for our example, we take on three stories totalling 15 Story Points, one of which is the unfinished User Story from the prior Sprint.

As we go through the Sprint, it’s very likely that we’ll finish the selected User Stories before the end of the Sprint. This is because the one left over from the prior Sprint, estimated at 8 Story Points, will have a lesser amount of work required and we’ve probably taken on less work than we can really handle.

In these circumstances, the Scrum Guide encourages the team to meet with the Product Owner and see what new work they can take in to the Sprint.

Again, for our example, we take on a new User Story estimated at 5 Story Points that we complete within the Sprint. Our new velocity now becomes 15 + 17 + 19 + 9 + 20 = 80 / 5 = 16

This example shows that moving unfinished User Stories back to the Product Backlog has only a temporary effect upon team velocity and presents the team with the occasional, simple problem of taking more work in to the Sprint.

Also, don’t forget that there’s no law saying that you must use the velocity as calculated. In the example above, you may decide to treat the Sprint result as an anomaly and continue with a velocity of 17.

How do you Prevent Inaccurately Forecast Sprints from Happening Again?

In the case of unforeseen circumstances, there is nothing that you can do. Best advice is to know how you will deal with the eventuality and do so consistently.

In the case of emerging trends, the ‘inspect and adapt’ cycle of Scrum is your friend. Take every opportunity to examine the circumstances and address the trend. Some examples I have come across before include:

• Over-optimistic developers. Even within small sprints, some developers will over-commit themselves. Best addressed with a one-to-one session
• Mini-Waterfall. The team start all of the User Stories within a Sprint and either finishes them late in the Sprint or, not at all. Best addressed by encouraging the team to do everything possible to complete single stories
• Poor estimating. Best addressed by getting the team together in a Product Backlog Refinement session and, with the benefit of what they’ve learned in prior sprints, re-examine the estimates provided for existing User Stories

This list is by no means exhaustive.

Summary

Finishing a Sprint with unfinished User Stories is a common event. How you deal with it depends on your interpretation of Scrum but best advice is to pick an approach and be consistent. Every time you finish a Sprint with unfinished User Stories, ask yourself why. If the circumstances are an emerging trend, use Scrum’s ‘inspect and adapt’ cycle to address the trend.

One final tip. To mitigate the problems of unfinished User Stories at the end of a Sprint, invest time up front in creating small sized User Stories.  The effect of an unfinished User Story estimated at two story points is far less than the effect of one estimated at 11 Story Points!