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 cancelled.
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 due to which the user story could not be completed. Let’s see 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 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 takup immediately in the next sprint.
One of the most common causes of 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 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 next sprint:
- The user story was underestimated and took more effort than expected
- Critical bugs associated with the user story was not closed
- A user story could not be closed due to delay in completion of dependant tasks
- Delays due to 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 on in multiple sprints
User Story is moved back to product backlog
In this case an unfinished user story is moved back to 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 :
- User story could not be completed due to dependencies which may take longer time to be sorted out.
- Resources required to complete the userstoy is not available
- User story is not refined enough,need more clarification and re estimation
- There are more high priority user stories to be taken up immediately
The story points associated with the incomplete user story is 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 which 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 as the examples below:
- The product owner believe that doing a partial release of the completed part will add value to the user
- The user story requires re estimation and the estimated storypoint is too large, which brings the necessity of story being split inorder to reduce it into smaller manageable chunks
- The completed section of userstoy is a bugfix or workaround which is critical.
In this case the storypoint of the completed story will be included in current sprint velocity and storypoint of the incomplete user story will be considered in the sprint in which it will be taken up and completed.
The User Story is cancelled
In rare cases changes in business requirements or the 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 product backlog. Following are some examples of such situation:
- The user story was a time sensitive feature and is not relevant after passing of the timeline
- Customer no longer require the feature
- It is discovered during the sprint that the feature is technically not feasible
How to handle story points associated with unfinished story
One of the most common questions asked in case of unfinished user story is ” what happens to the story point of the user story? Will the developer get credit for the effort put in the user story during the Sprint”. The answer here is No. The story point of any user story is counted in the sprint velocity, only if the story is marked as compared and forms part of product increment. The reason for this is that the story point is in a way, is an estimation of value delivered, or rather, value to be delivered. Since the incomplete user story is never delivered as part of 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 % work is still pending. So the velocity of the team for that sprint will be 20(4×5) 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 storypoint 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 the 6 user stories in the sprint the sprint velocity will be 30 story points. Now, a question arises, is this a realistic assessment of velocity of the team. In the example that we saw, even though the actual effort of the team in both the sprints was relatively the same, velocity of one sprint is 20 story points and velocity of the other sprint is 30 story points. The answer is, individual sprint velocity does not matter much. While calculating a teams velocity, we consider average velocity of multiple sprints and the fluctuations caused due to incomplete user story is evened out in the average. Even in the example that 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 sprint review. However the long answer is, 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 userstoy in sprint review even if it is not marked as done. Following are some examples:
- When the unfinished user story is split into multiple stories, completed user stories out of them may be taken up for demo.
- 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 compared 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 always not a reason to be alarmed. In Fact it is better to have spillover as a result of having a very stringent definition of done rather than setting the bar low for definition of done and marking all user stories as done. It also indicates that the team is pushing their limit and trying to take user stories to the brim of their capacity. It is like an infant falling while learning to walk. It matters how the team handles the unfinished user story and how they learn to avoid it.