Let's say, you are a Scrum Master and your team is in the middle of a Sprint. You see that all planned stories can't be completed till the end of the Sprint, that's for sure. What action will you perform?

  • Is this their first sprint together? Or is this the first time in a dozen sprints this has happened? – Al Biglan Mar 3 '12 at 2:35

10 Answers 10


It's wise not to interfere with the team inside sprint. Failure is healthier than a forced succes. Retrospective of a failed sprint is more interesting that a success sprint one.

PO should be warned but only if he dosen't have authority and opportunity to put pressure on the team. For him/her, a planned failure it's way more better than an unexpected one, even more if is a outside company client involved.

Make sure that information radiators are properly updated, and trust in your team until the last minute of the sprint! Any complains before the sprint ends may be seen like a lack of trust. When the fail it's declared stand by your team as it's your fail too. Don't look for guilty persons and don't let the team start this charade.

Work hard with stakeholders to create a tolerance for failure. The team should be ashamed not afraid to fail. If you don't have any tolerance for failure your team will force success by eroding quality and adding technical debts. You don't want that. NEVER stop a sprint because it may fail. It will be a living proof that you don't trust your team, and you'll be screwed as a ScrumMaster.

Learn to be patient.

| improve this answer | |
  • +1 for: emphasis on Team trust, and properly informing stakehoders. Great Answer. – Huibert Gill Mar 10 '12 at 18:04

If you're just talking about completing stories, I think you really only have two choices, alter the scope of the current stories or work more hours to finish the current stories.

To get back to your question, if I were the Scrum Master of a team who found themselves in this situation I would ask them what they think should happen and help them discover a solution.

| improve this answer | |

You have to either cut low priority stories or abort the sprint and start over.

You could also continue to the end of the sprint which leaves you with low velocity for the next sprint. This would allow you to do a better job of estimation next time around.

This is the point where many orgs simply abandon the core principles of scrum and start to add scrum-buts.

| improve this answer | |
  • I don't believe these are the only 2 options, there should be more :) – Michael Dubakov Feb 28 '12 at 21:33
  • Such as? "work more hours" - anti scrum. "lower quality" - anti scrum "add more devs" not within a single sprint. "cut features of stories" - your stories are not specific enough. – BNL Feb 28 '12 at 21:36
  • 1
    I will give you 'continue to the end of the sprint, have low velocity, learn from your planning mistakes' as a third. – BNL Feb 28 '12 at 21:39
  • It is similar to "switch to Kanban" type of advice, but I'll take it :) – Michael Dubakov Feb 28 '12 at 21:42
  • 2
    Having an iteration where you have to work a little extra to meet your commitment isn't anti-scrum, however, doing it every iteration does violate the idea of maintaining a sustainable pace. – Clayton Feb 28 '12 at 22:47

Don't abort the sprint, because this will demotivate the team ("Oh, just another sprint we couldn't finish.")!

Better: Inform the steakholders/POs about the situation and stories that might not be finished by the end of the current sprint. As you might have more than one story in a sprint and a given priority you should have at least a few other stories ready for release.

Important: Address this topic during the retrospective at the end of the sprint. Why didn't we (as in team) manage the finish the sprint - i.e. finish all comitted stories? Did we have an impediment? Did we have technical blockers? Did we just underestimate a bigger story? If so, restimate this story and take this one as reference story for the next estimation meeeting.

And last but not least: Learn to be patient - as Radu said in his very good answer.

| improve this answer | |

I'd do nothing. Our sprints are one week long. At the end of the sprint and when we prepare the next one we reflect on the old sprint.

In this case, as the team hasn't met the sprint objectives, it needs to learn from it and do a better job in the next time. As the team discusses the reasons for the failure, potentially moderated by a coach, they identify options for what they want to try out to do better next time. Over time the team will become better at achieving the sprint goals.

Of course if your sprints are much longer you may decide to choose a different option. In my experience interfering with the current sprint is usually the worst option and I try to stay away from it.

| improve this answer | |

During the teams stand-up when it becomes apparent that stories aren't going to be completed during the sprint I want to know:

  • Is it because the story was improperly estimated?

  • Is it because there was found work within the story? Was the found work due to complexity of the story or because in order to complete task A, task B must also be complete and task B was missed during design.

  • Are there impediments holding the team up that have not been brought forward? If so what are they and what can be done to remove them?

I've found that adding a 4th question to a teams stand up can help with identify when a sprint is off track. It also increases the teams communication and raises awareness of the sprint commitment.

How many points did we achieve yesterday on story xzy? (If nothing was completed, why?)

Use this question alongside the standard SCRUM standup questions and in my opinion your one step closer to a more productive team:

  1. What was achieved yesterday?
  2. What was achieved today?
  3. Is anything blocking progress?
| improve this answer | |

Immediately communicate up and down.

Down (team members). Ask what the problem(s) are that lead to this - don't assume you know the full picture. Ask how these came up. Ask what solutions people would recommend. Would priority would developers put on items? Which ones 'could' they do given the circumstances. A lot of these skills will be leadership skills in how to listen to your team.

Up (management). Tell management about this. Say this YOU made a mistake on the previous estimates (rather than 'explaining away with other 'reasons'). Ask management to look again at the priorities and determine which they want to do in the sprint given the circumstances.

The 'up' and 'down' might be done together but that's really going to depend on a ton of disparate factors about both the organization, its structure and the people involved.

Future. Try and make the take-away be that "things always happen" and, going forward, use this knowledge in future estimates to make them more realistic. Stuff ALWAYS 'comes up' and a good project manager accounts for this in time estimates.

| improve this answer | |
  1. Make sure the team is aware of this (and agrees with your assessment)
  2. Ask them how they want to handle this. Be sure you act as the "judge" reminding them of their definition of done, that keeping work open in parallel is "bad" and focusing on having a potentially shippable product at the end of the sprint (don't leave defects in the system)
  3. Before retrospective, collect the data, information, etc. that will help the team determine what to adjust for next sprint.

Of course, the answer really depends if this is the team's first sprint, or fifteenth together. If it their first, then it is probably more important to learn and understand why. If it is the fifteenth, you may just need to help the teem prioritize and ensure the sprint activities are well prioritized

| improve this answer | |

@Radu Impediment is poor nomenclature by me. Yes, meant for it to be solved at retrospective time. Apologies. Disagree with the rest of your post although it provides valuable insight and perspective on how some teams could react to scrum masters who do not "toe the line".

The past 18 years of mine have been spent working for stock exchanges and investment banks globally and the delivery cadence demanded by that business context is much faster than that generally provided by Agile methods (2-4 week sprint). Add to that, the dynamic of traders whose persona "overnight is long term" and margin for error is not that high.

My intersect with Agile is via Nonaka's SECI, Boyd's OODA and more recently Snowden's Cynefin and Ken's scrum. In my experience, most agile teams look at the practices as an end in itself without considering the dynamics of the business context and consequent impact on system design and service delivery design. This results in practicing agile without having the agile mindset and service orientation. As Kent Beck says, Agile is custom to the team that adopts it.

Teams should understand that failure to sprint goals is not about Agile but about a negative business outcome. Providing them the opportunity to learn about it is really a result of prevalent culture (Hoffstede, Schein, etc) more than the Agile process per se. Yes agile provides a forum via the retrospective, but content and outcome therein is really about deeper underlying triggers. Understanding the theory behind the process ensures we do not blindly apply what agile books tell us... i.e. without considering context.

| improve this answer | |
  • Thoughtful analysis :) However as I am not familiar with Nonaka / SECI / Byod / OODA / Snowden Cynefin / Hoffstede / Schein I missed a lot of it. – Michael Durrant Mar 10 '12 at 17:21
  • @ChimmyWagh - Hi, welcome to PMSE, the Q&A site for professional and enthusiast project managers. Our site format is a bit different from regular forums in that each answer you post should objectively answer the original question and not be in the format of a discussion. I've read this one a few times and it seems more like a comment than an answer. :) Consider taking the points you want to highlight from here -- that answers the question -- and edit your previous answer with those points. Thanks, and welcome to PMSE! – jmort253 Mar 10 '12 at 21:28

Raise an impediment for the team to problem solve on how would they handle this risk to business outcome, their credibility and planning depth.

| improve this answer | |

Your Answer

