When Is A Sprint A Failure?

(I originally posted this on my MSDN blog.)

Here’s another question that was asked on one of our internal distribution lists:

When do we consider a sprint to be a failure?  I don’t know the answer and have no clue about it.  We delivered 7 out of 9 stories we committed with all the release criteria, but we failed to deliver two stories due to under-estimation of the stories we picked.  Is this a failed sprint?

This stirred an interesting discussion about sprint commitments, continuous improvement, estimation, retrospectives, and numerous other things.  This was my contribution to the thread:

The phrase “sprint failure” in Scrum has a pretty specific meaning to a lot of people.  It means that at some point before the end of the sprint, you realize that your sprint plan has gone so far off the rails that the best thing you can do is to abort the sprint before it’s completed and build a new plan.

What if halfway through your sprint you realize that you’re probably going to be able to deliver only 7 of your 9 stories?  Should you abort the sprint at that point and plan a new one?  I guess it depends on the specifics of the stories but almost always I’d say no.  You’re a little off the plan but not drastically so.  That’s not uncommon.  Keep going, deliver value, and afterwards figure out if there are improvements you can make for next time.

The original poster is apparently not talking about aborting a sprint halfway through.  He’s talking about working until the end of the sprint then labeling the results.  I think he needs to define what he means by “failure” here.  Does he mean, “we should reflect on what happened and look for opportunities to improve?”  Sure, I agree with that, though I’d probably stay away from the term “failure” because it can be easily misunderstood.  Does he mean, “there are negative consequences imposed on the team?”  I emphatically disagree with that.  Not delivering 2 of 9 stories is not an outcome that should be punished.

If it’s treated as something to be punished then I guarantee that the team will adopt counter-productive behaviors.  In this case, they’ll probably just low-ball all of their commitments so that there’s very little possibility of failing to deliver.  This doesn’t help increase efficiency and reduce waste, though, because there’s no learning and improvement going on, just self-defense strategies.

One of the potential weaknesses of Scrum is that it’s easy to get too fixated on the concept of a sprint commitment and whether you fulfilled or failed to fulfill that commitment.  Some measure of predictability is important, sure.  But no estimation technique is foolproof and you can waste an awful lot of time trying to perfect something that is inherently imperfect.  Always remember that the goal is simply “good enough” estimation because estimation isn’t value, it’s just a means to an end.

I think this is one of the reasons why there’s been a lot of attention paid to Kanban and single-piece flow systems lately; because Kanban gets rid of the sprint timebox and all of the potential distractions that go along with it.  I personally feel that Scrum and Kanban aren’t mutually exclusive and if you merge the best of both systems you’ll knock the rough edges off of both.  (Some people use the term “Scrum-ban”.)  One of the best influences Kanban can have on Scrum is to put the concept of a sprint commitment into its proper perspective, that is, it’s a device for short-term planning, nothing more.  Relax!

The sprint retrospective is a powerful tool for change and improvement but it only works if you approach it from a positive perspective of “how can we become better?” rather than a negative perspective of “how badly did we fail?”.

Always beware the Law of Unintended Consequences.  Whenever you’re working with a system that contains humans you’ll find that some things you implement for positive reasons end up having negative results because they reinforce the wrong behaviors.  I think an over-emphasis on sprint commitments, and and insistence on labeling each sprint as a success or failure, is one of those things.