Agile SCRUM Scrum Master Spillovers July 25, 2020
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
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.
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!