It’s not that rare an occurrence for a scrum team to get to the end of a sprint and find that they have one or more stories that don’t meet the definition of “Done!”.

Question

This week from one of my former Professional Scrum Master students asked me about this situation:

”What should we do with un-done work at the end of the sprint?
I was thinking we have two options:
1) Move the user story to the backlog for re-prioritisation (maybe into the next sprint).  The problem here is that I’m not sure what to do with the story points as it screws up our sprint velocity
2) Split the user story.  In this case we would leave the old user story’s points as-is, then create a new user story with the remaining work and re-estimate with planning poker.
I was reviewing the scrum.org scrum guide and it doesn’t seem to have any details in this area.”

Answer

The lack of detail in the scrum guide should be enough indication on the approach to take. If the scrum guide doesn’t talk about splitting stories then it’s probably reasonable to assume you shouldn’t do it :-)

Putting the story back on the backlog for reprioritisation.  Sure, you won’t get any credit for the story in the current sprint because it’s not done, but it won’t screw up velocity either because velocity will be a true reflection of what you actually delivered during the sprint.  We want velocity to measure our rate of delivery not our effort. On average, over a number of sprints the velocity figures will average out in any case.  So yes, you may well have a few peaks and troughs when looking at single sprints but looking across the last 3 to 5 sprints you should have a good reflection of your actual rate of progress.

Not having a story finished and getting no credit for it also gives the team something to talk about during the retrospective. “Why didn’t we get to ‘done’ on story X?”.

On the flip side, I don’t like splitting incomplete stories because

1. it gives teams an “out” for not finishing properly and they get credit for effort not delivery. It stops them pushing for a goal and stymies the inspect and adapt process.

2. how do you actually split the story that was almost finished?  Can you split it in such a way that the work that was “almost” finished meets the “done” definition?  Can you do it in such a way that your product owner is absolutely sure that the completed part of the story is Done and that their acceptance criteria are satisfied? Can you cleanly separate the business value delivered between the completed part and the incomplete part? I doubt it.

Taking an incomplete story and splitting it just to make it look like you have a stable velocity reduces transparency and hides the truth of what you can actually achieve from your product owner, your stakeholders and most importantly yourselves.  Don’t do it.