What do I do When Tasks in the Sprint Plan are not Finished?

Posted on by

This is what having a large number of tasks unfinished at end of Sprint looks like:
Over commitment burndown

Not pretty.

It is best to avoid over commitment so the answer to “What do I do When Tasks in the Sprint Plan are not Finished?” is to lower your expectations next time you go into planning. Using Scrum language you should ensure the team only commit to what is achievable, and that is obviously less than they thought was possible the last time around.

You’ve also got to tidy the up the mess left by the previous Sprint. Have a look at the unfinished tasks and decide if they are necessary for your high priority user stories. If so, then schedule them into the next Sprint. If not, then forget about them.

Finally, you have to decide what credit you can give yourself, i.e. what velocity you earned in the previous Sprint. Personally I start hard line about this. You can only claim a user story if it is completed, so you can only add the story points for that user story if all the tasks have been completed. No partial credit.

Having said that:

  • If you find that the unfinished tasks are actually unnecessary then you can claim credit for the whole user story.
  • It is sometimes possible to split a user story into meaningful sub-parts. If one of the sub-parts has been completed then you can claim the story points of the sub-part for velocity

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.

6 thoughts on “What do I do When Tasks in the Sprint Plan are not Finished?”

  1. Hi, we are quite new to Scrum, our first few sprints were like your graph, with unfinished work. However, we now make adjustments throughout the sprint to ensure we hit 0 hours at the end. I mean, if half way through the sprint it is obvious we are way off finishing all the stories we will drop a story from the sprint, likewise if we are ahead we may add one. This isn’t a substitute for better estimation but things never tend to go exactly to plan. We thought this was a normal part of scrum (adjusting scope during the sprint), is that not the case?

  2. Chris, you’re doing it exactly right, i.e. adjust your commitment (scope) during the sprint to ensure you get to zero.

    In this post I focussing on what to do if the team hadn’t done that and was left with outstanding tasks.

  3. what happens if you have a work item that is longer than the sprint? Does that need breaking into smaller tasks?

      • Next question. What if you can’t do that? Let’s say it’s a single task? Do you have to create duplicate items?

        • Splitting user stories is a big part of managing within a Sprint. (And remember that User Story not equal Task.)

          Although I value story splitting, in fact view it as an essential skill in managing Lean-Agile requirements, splitting to fit within a sprint was one of the reasons I abandoned Scrum style time boxes for the continuous flow of Kanban. Splitting to fit within Sprint is a team/Scrum imposed constraint that I can do without.

Comments are closed.