What to do with an almost finished story at the end of the sprint? Finish it? Carry it over? Put it back? Count 90% of the story points? 100%? 0%?
We cannot predict the future. Unexpected things will happen and void our plans – no matter how thorough we plan. That is the reason for becoming agile after all! But what if our sprint plan doesn‘t work out? What if one or more stories are 90% done, but not yet ready to be released? This article gives hand-on advice from 20 years of agile product development experience.
The question has multiple aspects that we should tackle one by one:
- Should we extend the sprint a day or two to allow us to finish an almost finished story?
- What should we do with a story that is almost done, but cannot yet be released?
- How do we calculate velocity and story points in this case?
- Should we update the estimation after the fact, now that we know it was more work than planned?
Let’s go.
Do not extend the sprint
First I have to make clear that extending the sprint a day or two to finish a story is not an option. A sprint is a fixed rhythm, not a release package. In fact, sprints and releases should be decoupled at best!
Think of the sprint rhythm like the rhythm in music. Imagine to dance to a beat, if the band would “extend” every other bar of music arbitrarily to squeeze a few more notes in. It would be impossible to dance to. So don’t make your team stumble. Let them feel the steady rhythm of equal-length sprints. Feeling a rhythm is so much easier to dance to than having to expect a shorter or longer bar every now and then!
So if we shouldn‘t extend the sprint to finish the story, how can we deal with this partially finish functionality?
Carry over or put back on the backlog?
The general rule is:
If it‘s not 100% done (according to your definition of done), you just put it back into the backlog. You never release an unfinished story.
Of course this story had a higher priority than everything else that was in the backlog before the sprint. Assuming no dramatic shifts in priorities, this partially done story is still of higher priority than everything else on the backlog. So when putting it back, it most likely ends up on top of the product backlog.
In the sprint planning for the next sprint, you can pull it into your sprint backlog first thing. Since the review, retro and planning are happening back-to-back, this procedure is essentially a “carry-over” to the next sprint. It’s fine to put it right into the next sprint backlog without a detour through the product backlog. Just remember to consider any changes in priorities since the last sprint planning – especially through the feedback you got during sprint review. This could lead to you deprioritizing the story in the backlog to make room for more valuable stories.
Up to now we treated the story as one solid block. And that is good, because it prevents us from releasing a story that is not tested to our standards or lacks parts of its functionality. Such a story could not deliver the promised value to the customer.
But what if we can split the story into two or more valuable chunks after the fact? If we managed to implement one part of the workflow, but the more obscure second use case is not finished yet?
If we can split the story into two valuable chunks AND one of these chunks is done (according to our definition of done) and can be released, then we should go ahead and do it!
The new, smaller story can be demonstrated in the review and released to the customer. We mark it as done and get it out of our mind (well, we still have to track metrics to validate our hypothesis when the customers use it; but from an implementation point of view, it’s done).
The second (not yet finished) story goes back onto the backlog. We deal with it as we would’ve with the whole user story above: Put it back, re-prioritize if needed, then pull it into your sprint planning.
Nice. Now we dealt with our story, the next question arises: What do we do with the estimation in all these cases?
How many story points?
If a 90% finished story is carried over to the next sprint, a common instinct is to attribute 90% of the total estimation (usually in story points) to the last sprint, adjust the story’s estimation to 10% of the original estimate and use that as an estimate in the next sprint. But that is a bad way to deal with it – don’t do it! Why?
First, we want to establish a value focus (customer focus) in an agile team. If something delivers zero value to the customer, it shouldn’t be counted. Yes, we worked on it, but the customer only cares about results (when did you last thank a car manufacturer for working twice as long on your car delivery?). Instead of letting us get carried away with the excuse of “we were busy working on it” and looking at vanity metrics, we should re-focus on the value we deliver to the customer as often as possible.
Second, who actually knows whether the story is 90% done? It could also be just 50% done and we wouldn’t know! Yes, old-school project management tools may claim to know, because they count the number of finished tasks or some other bs metric – but that is a relic from the waterfall world. In an agile world we humble to admit, that we cannot predict the future. Who knows whether the last 10% of that story contain a nasty to hunt edge case that causes incompatibilities with existing features and takes us as much time as the first 90% of the story? Things like that happen all the time – it’s the very reason why traditional projects are regularly over budget and delivered too late.
The only sensible thing we can do is to consider such a story in a very binary fashion: it’s either 100% done or 0% done. Consequently 90% done means “not done” and we attribute 0% of the story points to the last sprint. Only stuff that can be released to deliver value to the customer gets counted in the velocity.
The story is either put back onto the backlog with its full original estimate or carried over into the next sprint with its full original estimate.
If you put it back onto the backlog and decide not to continue it in the next sprint, you should know that half-done work can (and will) rot. But that’s the topic of another article.
If you carry the entire estimation over into your next sprint, then simply let the team decide, how much else they can take into the sprint. Maybe despite the story points of that half-done story, they feel confident to tackle a little more this sprint.
I already here the statistic lovers freak out: “But, but, but wouldn’t that totally skew the velocity metric? The first sprint would have a fairly low velocity despite a lot of work being done, while the second sprint as an artificially high velocity without much work getting done on that 90%-done story!”
Chill! That’s my usual reply ?.
If you think more in “value delivered” than in “time spent working”, this “skewed” velocity represents reality even more realistically.
Furthermore, since we usually use a moving average over the last 3 sprints to get a feel for how much we can take on in the next sprint, the fluctuations vanish in the averaging process anyway.
Lastly, velocity is not some golden metric that we must get right to the second digit after the decimal point. It’s just one of many indicators a team can use to get a feel for how much they can plan for the next sprint. Heck, some teams even plan without velocity and story points at all! So don’t waste your precious energy on this metric and rather focus on delivering value!
And to focus us on delivering value, nothing is better than having our metrics aligned with what delivers value. Avoid aligning your metrics with what produces work!
The final thing to talk about is: Should you update the estimation of the story?
Should you update the estimation?
We already talked about the possibility of potentially splitting the story into a “done” (and releasable) part and a not-done (ideally not even started) part. In that case, talking about a re-estimation of the story can make sense.
Again, don’t hold the accuracy of estimations to highly! It’s only a rough indicator to help you gauge how much you can likely deliver up to a certain date. Still, it might make sense to quickly re-estimate the story.
Agility is all about learning and adapting. You’ll likely have more insight into the story than when you first estimated it. And since you weren’t able to finish it in the last sprint, it’s likely some new information (e.g. about tricky edge cases) presented itself and made it more complex than you thought. If it helps you, you can totally update the estimation, before you put the story (or the split-off new story) into the product backlog or straight into the next sprint backlog.
Remember: If you split the story, the two new stories’ estimates do NOT have to sum up to the original estimation! It’s totally possible that the original story was a 5 and after the split they are a 8 and a 5. Remember: We learn! Nobody made a “mistake” estimating the original story. We just didn’t have the information and insight back then that we have now.
Adjust the estimation, if it makes sense for you. But please don’t waste too much time getting it “right”. That last recommendation goes for estimating in general!
Btw: If your velocity and estimations are (ab-)used outside of the team for by people not part of the team, you have a different problem. But that’s also another full article!
Learnings: Cut your stories smaller
Before I close, I want to emphasize the agile growth mindset. Not even should we know how to deal with 90% finished stories, but we should also learn how to avoid this situation in the future.
To be clear: Unfinished work at the end of a sprint is not a failure or a sign of immature teams. Quite the contrary! As agile teams are humble in admitting that they can’t predict the future, it will always happen that things didn’t work out as planned. The first step towards agility is admitting this and viewing it as an opportunity to learn.
So what can we learn?
Apart from the specifics that may have caused your story to be more complex than anticipated, you can look at how big your stories are in general.
The simple rule: smaller is better. (Up to a sensible point). These partially-finished stories are usually pretty big. Starting with a backlog of more fine-grained, smaller stories drastically reduces the risk of having a huge chunk of unfinished work at the end of the sprint!
Try to split your stories into chunks that take no more than 2 or 3 days to get to done. Of course you need ensure, these smaller stories still have value for the customer and can be released separately.
Key takeaways
- Never extend a sprint. You will only trip the dancers.
- If it’s not 100% done, don’t release it.
- Split into a 100% done and an unfinished part only if both create business value on their own.
- Put the unfinished story back on top of the backlog. Reprioritize if needed.
- Eventually pick it up again in the following Sprint planning.
- 90% done stories count as 0 story points. This keeps the focus on delivering value.
- Aim to make your stories smaller, so they can be finished in 1-3 days.