Unfinished Stories in a Sprint

Question

Every so often, we find ourselves with a story that, for some reason, does not get completed during a sprint. This could be for a variety of reasons, such as a tricky bug, but the end result is that the story is not done.

I understand that unfinished stories can be an indicator of bad story writing, but despite our best efforts though we do come across an unfinished story from time to time. So far, we have just carried the story over into the next sprint.

Is this the right thing to do? Also, are the full points earned upon completion in the next sprint or will this skew the velocity of that sprint?

Answer 1

There are a lot of reasons for an unfinished story. Perhaps it was poor estimation, and more work was needed than the team thought at the beginning. Perhaps it was too large and should have been broken up into smaller stories. Perhaps a team member had to take an emergency leave, leaving the team with fewer contributing members for a day or two. It does happen from time to time, so you should be tracking why it's happening and taking corrective action if you can. That's something to discuss at your retrospective meetings and postmortems.

So, now, you have an unfinished story. That means you didn't get any points for it in the iteration that just finished. Assuming the priority of the story hasn't changed, it gets moved into the next iteration. Since your velocity for the previous iteration was lower, you now take fewer points into the next iteration. If your velocity for the previous sprint was X and the unfinished story was worth Y points, move the next (X-Y) points into the current iteration.

You now have a full backlog that you will be working on for your iteration. However, one of the stories is actually partially completed. One of two things could happen. You might finish all of the points early, before the sprint ends. Or, depending on how much work had to be done to complete the story, you might finish on time. If you finish all points at the end, you're good - just calculate your velocity and plan the next iteration. However, if you finish early, you have a few options. You could move another story into the sprint, beginning design and implementation of it, with the understanding that it might not be finished. Or perhaps you'll give your team some time to do corporate-mandated training. Or maybe just do some refactoring or write a few extra test cases that you've been meaning to get to, but weren't a high enough priority to do.

In the end, don't worry about skewing velocity. It's all about using your time appropriately. Velocity normalizes over time. You might have deviations in different sprints, but your retrospectives can explain why it happened and what you are doing to correct it for the future.

Answer 2

At the end of the sprint, any stories which are not complete are put back into the backlog. At that point, the normal routine of backlog grooming and prioritization can take place. If the story is still a high enough priority, it will make it into the next sprint.

I wouldn't get too caught up on re-estimating the story, but what you can do is to split the story into smaller pieces where some of the resulting smaller pieces become completed stories and the rest become new stories representing what's left. Again, probably not worth going through the trouble to do this very often.

Answer 3

Good answers from Clayton and Thomas. I like how Clayton mentions that you do not automatically rollover the story into the next sprint.

I would add a couple of thoughts:

1. The story may not be finished because the team is so focused on their individual work that they forget about the team commitments. Having too many stories in progress can put you at risk of not finishing some stories. If you're not already doing so, consider limiting your work in progress and having the team collaborate on stories so that stories get completed earlier and if you have under-estimated your sprint backlog your incomplete stories will be fewer and perhaps not even started. This will also help you pull extra stories into the sprint if you have over-estimated.

2. Some teams (likely not yours) are just not that good at breaking down stories. It could be that your unfinished story is made up of child stories and by splitting the story at the end of the sprint there is something that you can deliver. Don't make this a habit though and never split a story across the process dimension (analysis, design, build, test).

Answer 4

Just a note about velocity ...

1. Unfinished stories count for zero velocity in this sprint.
2. Yes, this means that your velocity is particularly low for this sprint, however it evens out on the sprint when you do include this partially finished story.
3. Velocity should really be shown as a moving average over a number of sprints in order to "smooth out" the lumps and bumps - just take the average of the this sprint and the previous 2 or 4 sprints and next sprint take the average of that sprint and the previous 2 or 4.