Incomplete stories

Over the years, I’ve heard a common recurring belief or practice related to incomplete stories in a Scrum sprint that I want to state my opinion on.  Here’s the scenario, as I’ve heard it described by others:

(upon asking someone how they handle when a team cannot complete a story in a sprint)

“Well, if we run into trouble in a sprint, and we can’t finish a one or more stories for whatever reason, we pull them out of the sprint backlog for this sprint.  Then they go into the next sprint backlog so we can finish them”.  

I inevitably stop the person right there…I say “well, I think what you actually mean is that you put those items back on the backlog for reordering…right?”.  “Oh yeah, that’s right” is the response I most often hear, but I’m not sure that’s genuine because that’s not how it was described to me in the first place. 

Continual reordering is critical to ensuring that what software is being delivered is of the highest possible value.  By taking an incomplete story, and automatically pushing it into the next iteration, you are effectively saying “this is the most important thing that we should work on next”.   Often, I find that’s not the case – if that thing were that important, it probably would have been completed in the prior iteration.  The mere fact that it’s not yet done signals to me that it might not be that important.  

Often though, because you have sunk some amount of work into an incomplete story, that you want to see some return on that investment.  Say across your entire team, you’ve spent 30 hours of effort building a story that was not completed in a sprint – that represents real money that your employer or customer has invested.  Say you believe that you have less than 10 hours left of effort across your team to complete that story.  It is awfully compelling to invest that 10 additional hours of effort, and see that value realized.  You have to balance that decision against not investing those 10 hours to start another story.

The next time you have an incomplete story in a sprint – I encourage you to think about the implications of completing that story over starting something new (that may not have existed when you started the last iteration).   Balance the remaining work and value to be delivered against the next highest ordered stuff on the backlog.