4 steps to manage unfinished stories at the end of a Sprint.
It is the last day of your Sprint. You still have unfinished stories in your Sprint Backlog. What do you do?
It is common for Scrum Teams to have unfinished stories at the end of a Sprint. We all know that this trivial situation raises many questions.
- Can you avoid having unfinished stories at the end of a Sprint?
- What do you do with the unfinished stories themselves?
- Should the Scrum Team get any velocity points for completing only a portion of the story?
These questions and their answers are subject to debate. It took me many sprints to come up with my own answers. I believe I have at last established a coherent and viable process to manage this situation.
Today, I like to apply the 4 following steps to manage unfinished stories in a sprint.
- Identify the stories that you won’t be able to finish.
- Document and estimate the remaining.
- Send these stories back to the Product Backlog.
- Take the unfinished stories to the Sprint Retrospective.
In this post, I will explain how our Scrum Team manages its unfinished stories in a sprint. Here, it is all about my personal experience (and preferences). I hope my practical tips and tricks can help you if you are seeking for guidance in this situation.
Unfinished stories are inevitable.
If a Development Team member starts working on a story, he should feel confident that he can complete it before the end of the Sprint. But, self-confidence is not a guarantee. Many reasons could prevent him from finishing stories before the end of a Sprint.
I selected the 4 main reasons why our Scrum Team ends up with unfinished stories.
Some tasks turn out to be more complex than expected and estimated. It happens that developers « finish » their stories late on the last day of the Sprint. If there is no time left for code review, our Scrum Team usually prefers not to rush it. Hence, the story remains « in progress ». Then, production issues and bugs impact the sprint. We always put production first! And, Development Team members get sick from time to time. This is part of being human I guess.
I truly believe that our Scrum Team has little to none control on these events. They happened many times and will happen again. We will assume it is probable that you end up with unfinished stories in a sprint. How do you manage this situation? This I don’t know…
But, here is what I do.
1. Identify the stories you won’t be able to finish.
The Scrum Team should quickly be able to identify the stories it will not finish. I see 2 reasons why this is important. The Scrum Team can react accordingly to finish the Sprint. The Product Owner can communicate accordingly with stakeholders. Therefore, a few days (2–3 days) before the end of the Sprint, our Scrum Team members start challenging each other on « in progress » stories.
Here is the trick.
During the Daily Scrum, we make sure participants answer to: « do you think you will finish your stories in this sprint ? ». This comes on top of the 3 well-know questions.
Including this question does have an impact. It raises awareness among all participants. “We must finish this important story to reach our Sprint goal. It is currently in progress. Guys, let’s make sure we get it done !”.
Very important.
It might be difficult for (some) developers to admit they won’t finish a story. But, this information is critical to manage the end of the sprint. If someone needs help, you better know it as soon as possible. Therefore, it is key for the Scrum Team to build a judgment-free environment where everyone can speak openly.
2. Document and estimate the remaining.
You have now reached a point where you know you will not be able to finish some stories. What do you do now? Scrum Teams are often torn on this situation. Some will not think about it and finish their stories asap, which I can understand. Others will try to find a proper way to manage their unfinished stories. Here is how our Scrum Team proceeds.
We first document the remaining.
We add a new section called “Remaining” to the story description. This can be done by the Development Team member (with the help of the Product Owner if necessary). In this section, the we describe what is remaining to complete the task. Or, the assignee could describe what has been implemented (only if it helps). This should not take much time.
Someone who just spent several days working on a story knows exactly what is remaining. Therefore, it is best to write this small extra description right away, while it is still fresh.
I am advocating for this “Remaining” section. In fact, it helps to put words on the reasons which are preventing the Development Team from finishing the stories. With words, you will get a better understanding of the situation. This is a great opportunity learn.
We finished documenting the story. We then estimate the remaining.
The Development Team member who worked on the story can use the “Remaining” section to give a new estimate to story. Or, the Scrum Team could do it during the Backlog Refinement. This is up to your planning.
Here is a scenario we often encounter.
Let’s say the initial estimation for a story was 8 points. The Sprint finishes. There is only the code review remaining to complete the story. The Development Team member who worked on it would probably estimate the remaining to 1 point. If the remaining consisted of writing acceptance tests, then the new estimation could be 3 points. This is up to the Development Team member’s experience and common sense.
Time to answer the critical question.
Should the Scrum Team still get any velocity points for the stories it did not finish?
There are my ways to answer this question. Here, I am explaining how our Scrum Team decided to manage velocity points.
My personal view on this one is a little drastic. Our Scrum Seam only gets velocity credits for the stories it finishes. It is binary: “Done” or “Not done”. As a team, we want our velocity to reflect what we are able to complete in a Sprint. Therefore, our Scrum Team does not get any velocity points for unfinished stories.
3. Move the story back to the Product Backlog.
This is serious. You should never automatically move an unfinished story to the next Sprint. You should first move it to the Product Backlog where it will go through prioritization (again).
Why should you move it the Product Backlog first?
The Product Owner is responsible for prioritizing the Product Backlog. He should decide on what the Development Team will work on next. An unfinished story from a previous sprint will probably get a high priority. In fact, it is nice to finish something you started. But, the priority of a story might change from one sprint to another.
When should you move it to the Product Backlog?
This is a tricky question. I like to do it on the last day of the Sprint. Why so? Because it does not matter so much to do it earlier. And, because you never know… There is always a chance the Development Team manages to finish the story. For example, other Development Team members might finish their stories early. They could help. Or, the developer might have a stroke of genius.
4. Take the unfinished stories to the Sprint Retrospective.
This might be my favorite part of the process.
I really like to take the unfinished stories to the Sprint Retrospective. It is a great opportunity to reflect on what happened. Why were you not able to finish this story? Was the description incomplete or unclear? Did you have technical problems?
Here is what happens.
We start our Sprint Retrospectives discussing the stories we did not finish in our last sprint. The Development Team members share their insights on the unfinished work. At this point, the Scrum Team is (very) familiar with the stories. Therefore, we mainly focus on the « Remaining » section.
It only takes 5 to 10 minutes every 2 weeks. And this only happens if you have unfinished stories in a Sprint. This practice helped us detect recurring issues and work on them. For example, we noticed that we often did not finish stories because of tests. We realized that we underestimated these tests in our estimates. So, we reacted. Today, during the Sprint planning, we discuss the tests for the stories and take this aspect into consideration for the estimation.
This is a great learning opportunity that does not cost much.
In Brief.
Step 1. A few days before the end of the sprint, during the Daily Scrum, we raise attention on stories we might not be able to finish. This gives an opportunity to act as a team to finish the necessary work. As for the Product Owner, he gets the chance to communicate with stakeholders accordingly.
Step 2. The Sprint is about to end. The Scrum Team knows it will not be able to finish some stories. We document and estimate the remaining work.
Step 3. We move the unfinished stories to the Product backlog. We close the Sprint. The Scrum Team only got velocity credits for completed tasks. The Product Owner can (re)prioritize them according to the remaining and the estimate.
Step 4. We take the unfinished stories to the Sprint Retrospective. The Development Team members share their insights. We learn and we improve as a team.
Conclusion.
In this post, I wanted to share the most efficient way I experienced managing unfinished stories in a Sprint. I took you through 4 steps that frame this trivial situation. I really feel like these 4 steps smoothly lead the story through its natural life cycle.
How do you manage unfinished stories at the end of a sprint ? What are the main reasons that prevent your Team from finishing the Sprint Backlog? Do you also take these stories to the Retrospective ? What do you think about these 4 steps?
I’ll be more than happy to have your feedback and read your questions and comments.
My last article was definitely more fun than this one ! I explained what our Scrum Team does when finishing a Sprint early.
Regarding the unfinished stories in a Sprint. I would also recommend you read:
Thank you for reading !
