How to Handle Unfinished User Stories in a Sprint?

When a user story or product backlog item in the sprint backlog could not be completed by the end of the sprint, it is called a spillover. Unfinished stories or spilled-over user stories are mostly moved back to the product backlog and will be taken up in the next sprint or a future sprint. If the user story is no longer relevant after the sprint, it could even be canceled.

The decision on what has to be done with an unfinished user story or spillover is taken by the product owner. This decision depends on the reason the user story could not be completed. Let's look at the different ways in which unfinished user stories are handled in detail.

What is Done with the Unfinished User Story Itself

The User Story is Moved to the Next Sprint

One of the most commonly practiced options when a user story could not be completed within a sprint is to move it back to the backlog and take it up immediately in the next sprint.

One of the most common causes of an unfinished user story is a lack of time to complete the user story within the sprint. In Scrum, there is no option of extending a sprint to complete an unfinished user story. So, the obvious choice here is to extend the development of the user story to the next sprint and complete it. Following are some examples where the product owner may choose to move the user story to the next sprint:

• The user story was underestimated and took more effort than expected
• Critical bugs associated with the user story were not closed
• A user story could not be closed due to delays in the completion of dependent tasks
• Delays due to the unavailability of developers due to unplanned events

In this case, the story points allocated to the user story will be considered for velocity calculation only in the sprint in which it was completed, even though its development took place in multiple sprints.

User Story is Moved Back to Product Backlog

In this case, an unfinished user story is moved back to the product backlog and is not taken up in the immediate sprint. It is left in the product backlog and will be taken up in an appropriate future sprint. This option is chosen when it is either not practical to take up the user story immediately or there are more priority user stories in the backlog that have to be taken up first. Following are some examples:

• The user story could not be completed due to dependencies, which may take longer to be sorted out.
• Resources required to complete the user story are not available.
• The user story is not refined enough, needs more clarification, and requires re-estimation.
• There are more high-priority user stories to be taken up immediately.

The story points associated with the incomplete user story are parked and will be included in the future sprint in which it is taken up again.

User Story is Split into Multiple User Stories

In this case, the user story that is not complete is split into multiple smaller user stories, and the original story points will be distributed among them proportionally. This is mostly done so that the completed portion of the user story can be separated and marked as completed, and only a small part of the original user story will be considered as incomplete and will be a spillover. This is not a recommended way of handling incomplete user stories, except in special cases such as the following:

• The product owner believes that doing a partial release of the completed part will add value to the user.
• The user story requires re-estimation, and the estimated story points are too large, which brings the necessity of splitting the story in order to reduce it into smaller, manageable chunks.
• The completed section of the user story is a bug fix or workaround, which is critical.

In this case, the story points of the completed story will be included in the current sprint velocity, and the story points of the incomplete user story will be considered in the sprint in which it will be taken up and completed.

The User Story is Canceled

In rare cases, changes in business requirements or circumstances will make the user story irrelevant. In such cases, the product owner may choose to cancel the user story. These user stories will be removed from the sprint backlog as well as the product backlog. Following are some examples of such situations:

• The user story was a time-sensitive feature and is no longer relevant after the passing of the timeline.
• The customer no longer requires the feature.
• It is discovered during the sprint that the feature is technically not feasible.

How to Handle Story Points Associated with Unfinished Stories

One of the most common questions asked in the case of an unfinished user story is, "What happens to the story points of the user story? Will the developer get credit for the effort put into the user story during the sprint?" The answer here is no. The story points of any user story are counted in the sprint velocity only if the story is marked as completed and forms part of the product increment. The reason for this is that the story point is, in a way, an estimation of value delivered, or rather, value to be delivered. Since the incomplete user story is never delivered as part of the product increment, there is no value delivered as part of the user story and hence is not counted.

For example, if there are 5 user stories in the sprint backlog with 5 story points each, by the end of the sprint, if the team is able to fully complete 4 user stories and 95% of the fifth user story, only 4 user stories could be closed, and one remains open because 5% of the work is still pending. So, the velocity of the team for that sprint will be 20 (4x5) story points.

Assume that in the next sprint, the team again plans to take up 5 user stories of 5 story points, plus the spillover user story. The total planned story points in this case is 30. However, the effort will be close to 25 story points only, since 95% of the spillover user story is already completed. If the team manages to complete all 6 user stories in the sprint, the sprint velocity will be 30 story points. Now, a question arises: is this a realistic assessment of the team's velocity? In the example we saw, even though the actual effort of the team in both sprints was relatively the same, the velocity of one sprint is 20 story points and the velocity of the other sprint is 30 story points. The answer is that individual sprint velocity does not matter much. While calculating a team's velocity, we consider the average velocity of multiple sprints, and the fluctuations caused by incomplete user stories are evened out in the average. Even in the example we discussed, the average velocity is 25, which is realistic.

Should We Demo Unfinished User Stories in Sprint Review?

The short answer to this question is no, we do not consider an incomplete user story in the sprint review. However, the long answer is that, in most cases, an incomplete user story is not demonstrated during the sprint review. However, the user story is discussed when the product owner gives the stakeholders an overview of completed and incomplete user stories in the sprint. There could also be exceptions where the team decides to demo a user story in the sprint review, even if it is not marked as done. Following are some examples:

• When the unfinished user story is split into multiple stories, the completed user stories out of them may be taken up for demo.
• The product owner feels that the feature is important, and showing it early to stakeholders will be beneficial.
• The feature is ready for demo, but the story could not be marked as complete due to technical reasons (for example, performance testing could not be completed due to unavailability of infrastructure required).

Closing Note

Having unfinished user stories at the end of a sprint is not unusual and is not always a reason to be alarmed. In fact, it is better to have a spillover as a result of having a very stringent definition of done, rather than setting the bar low for the definition of done and marking all user stories as done. It also indicates that the team is pushing their limits and trying to take user stories to the brim of their capacity. It is like an infant falling while learning to walk. What matters is how the team handles the unfinished user story and how they learn to avoid it.