How to deal with unfinished user stories from a sprint

[pranjal kohre]

Hi Team,

Just wanted to know your inputs or may be what are the best practices to follow in our case.


We include stories in our sprint but it gets associated with tasks and sub-tasks since multiple people work on the same. As part of sprint estimation, we usually calculate the overall estimate of the story only (estimations for subtasks, tasks associated with the user story generally roll up to the story estimate only). 

When we close the sprint, it is possible that a few tasks or sub-task (associated to that particular story) might remain incomplete. In this case, please suggest what is the correct way forward -
1. Shifting the overall story to next sprint and re-estimating it with the remaining story points? - In this case, the burn down report will not account for the estimations of completed tasks since it generally reports at story level only which in this case doesn't get completed OR
2. Closing the unfinished user story (marking it as v1) by unlinking the incomplete task to it and Opening a v2 version of the same user story and linking the remaining task here with remaining story points? - In this case, the burn down report will correctly estimate the efforts of previous but the splitting of user story may be just for the sake of allowing Jira to record the efforts. There may not be anything wrong with this but it looks like a bad practice that also defies the definition of user story.

Please suggest what should be done in such cases or may be if there is a 3rd option which is better than everything above? 

[Mark Segall · Accepted solution]

Hi @pranjal kohre and welcome to the community!

I would opt for option 3 which is simply move the issue to the next sprint.  Planning velocity should be around how much work is RESOLVED by end of sprint.  If work gets started, but not finished, it simply doesn't count toward your velocity for the current sprint.

So, let those issues, regardless of the state of sub-tasks move to the next sprint and count toward velocity of the next sprint. It all equals out over the course of time.  If your previous sprint velocity took a dip, it's likely not the result of the stories that carried over.  As part of good sprint retro hygiene, the sprint should be evaluated for whether the stories were well crafted, whether there was opportunity to break them down further, or if any unforeseen circumstances impacted the sprint (production bug, unexpected PTO, etc.).

[pranjal kohre]

Hi @Mark Segall thank you for taking out time to provide your valuable advice

Your answer makes sense but also let me know what do you advise for its re-estimation. For example - if the original story was 10 points and work remaining at the end of the sprint for this story was worth 2 points, should we mark this story as worth 2 points in the next sprint since this is the actual estimate now? Also if we are doing this, aren't we losing the 8 points worth effort somewhere?
In case we don't do that above and just mark the story as worth 10 points in the next sprint, won't it be an unrealistic estimation? Aren't we overestimating by 8 points?

Just wanted to know your thoughts around this.

[Mark Segall]

No need to re-point. It just carries forward the velocity to the next sprint so the full effort is captured on the next sprint. It may seem like a dip on your first sprint but will equal out over time. 

[pranjal kohre]

But then how do you plan the efforts for the next sprint? Wouldn't keeping the story points same make you look like you are more loaded? Or you simply take less work in the next sprint? 

[Mark Segall]

Short answer is that it depends. If the team is feeling bullish that the remaining work on the carry over story is minimal, they can plan for their full velocity. Otherwise, they can plan for less. The main thing is that velocity will even out over time. It always takes a good 3 or so sprints to settle into a groove and I’ve found that carry over work should even out as well. It’s totally natural for a healthy team to have one or two issues carry over because work doesn’t magically fit into an artificial time box. However, the total velocity should average out over time. 

[pranjal kohre]

Understood @Mark Segall 

I would suggest my team to take a call in such cases and would leave upto them if they want to consider full points of the unfinished story while planning their work in next sprint.

Otherwise if the unfinished work is too small, they can choose to consider full bandwidth of the fresh work as you mentioned.

Thanks for all the insights. I am just catching up since I have joined a new organisation and teams are starting from scratch here.

[Bill Sheboy]

HI @pranjal kohre 

Yes, and to Mark's suggestions: a key idea is paying attention and experimenting to improve...rather than focusing on "earning points" as some other teams might do.

During the sprint retrospective, the team may review the complete and incomplete work to understand "why" things happened the way they did.  What was different about the work items or the way work was done than was unexpected from this sprint's plan?  Has that happened before, and if so: why?

Perhaps there are improvements to backlog refinement (e.g., sizing, splitting work, clarifying the need), to delivery (e.g., focus, knowledge sharing, swarming), etc.  Any of these may reveal experiments to try for improvement. 

Kind regards,
Bill