Mar 15, 2012

What do I do With Partially Completed Stories in Scrum?

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!”.


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 guide and it doesn’t seem to have any details in this area.”


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.


  1. I avoid splitting because it creates a false sense of progress. A pattern I have seen is that teams close the story and just log bugs. That's probably worst, if you create a different story at least you would split by scope, not by quality.

  2. Hi Richard,

    recently stumbled upon your very interesting blog while trying to figure out how to deal with the agile-delivery-fixed-price problem (really loved the approach you suggested, the post is from 2007, but I think it's still relevant).

    As for the problem you discuss in this post, this is something that I was also wondering about. I understand the reasons that speak against splitting, but I am wondering about some details. Let's say the team takes on 10 stories for a sprint, each of them estimated 10 points, but two of them remain unfinished. Now we push the two unfinished stories into the next sprint, keeping in mind that they are almost done. Do we re-estimate them? If we do, the new estimation will be very low, let's say 1 point each. The other 18 points will never be accounted for. If you leave the efforts, wouldn't it mean that, consequently, you should take on less stories into the sprint than you can accomplish, since you already have two stories worth 20 points in the sprint?

  3. Any response to above question..I am in the same boat

  4. @ilja_v and @anonymous Don't resize them. The story size hasn't changed.

    Also, remember that the goal is not to have a fixed velocity, or to use it as a maximum number of points to pull into a sprint. The goal is to deliver software as efficiently and quickly as you can. In the next sprint take on the two almost complete stories, plus as much other work as the team thinks it can do.

    Also remember that velocity is averaged across sprints, so if in sprint 1 you completed 80 points and in sprint 2 you completed another 80, plus the two outstanding stories of 20 then you're average velocity would be 90.

  5. Hi Richards, thanks for the reply. Is it right to assume than, that, when operating with short sprints, it is a normal thing for the velocity to be very "jumpy" rather than constant? Following the rules you describe above, the velocity in our sprints would be something like 30-70-40-60 rather than 50-48-52-50.

  6. Thanks for this, I've been struggling with this exact problem. Splitting the story has always seemed to be the wrong solution to me, as it hides the problem instead of allowing the team to inspect, adapt and improve

  7. Great post. I have a related question. Can the PO deliver the content that was already developed and tested, even though the story itself will be moved to the backlog? Assuming, of course, that the completed content is of value to the customer.

  8. @Erez It depends on the state of the product increment. If the partly completed functionality has been incorporated into the product, and the product is 'done' (i.e. production ready) then it's possible. I'd be dubious and very wary of doing that though as it's much more likely that the partially completed work is also only partially tested and partially integrated.

  9. If bugs are found related to a user story, is the story done or not?
    If not, this means a user story is only done is you are sure no bugs will be found (ever) that can be related to that story.
    Does it matter for the velocity wether or not the bugs are found during the sprint in which the story is implemented or in any next sprint? If so, does that mean that finding a bug for a already done story, that this story is reopened and that the velocity of the sprint in which the story was implemented is decreased by the number of points assigned to story?

    In my sprints (I'm either a product owner or a scrummaster, depending on the project/team) the points count for the current sprint if the bugs are not blocking the release of the story; and the story is considered as 'done'.
    The bugs found are pushed back on the product backlog and the product owner can decide when and how to address these bugs. Fixing the bugs will be a new user story.

    If we consider the story as 'not done' if bugs are found in the same sprint where the story is implemented, this could prevent the team reporting the bugs.