So your team is running Scrum, you have a two week sprints, and things are going well. That’s wonderful! At the beginning of your next sprint the team has a few concerns about some of the User Stories (items, features, whatever you call them), but those are minor and you shave a few points off this sprint to make up for it. With your planning done the sprint officially begins and everything seems great.
A week goes by and every daily scrum is marred by blockers. At this point your team should have been further along, but maybe that isn’t too bad. You have seen in the past some sprints have everything polished off and come in during the last quarter of time, maybe this is just ‘one of those sprints.’
Another half week goes by and the team has started to act like they are in a crunch. Nothing substantial finished, several items not even started. At the end of the sprint the team slinks into the retrospective to discuss what went wrong. It is about at this point that your team likely has one of two reactions. Either the team is cavalier and dismisses the sprint as a one-off, or they are beating themselves up over it and feel like they have just failed. Both of these reactions leads to the problems of “what does failing a sprint mean,” “what are the consequences for failing a sprint”, and “if there are little to no consequences, why do sprints matter?”
Lets look at each of those questions more in-depth. First, “What does failing a sprint mean?” I look at this like the US Supreme Court’s 1964 Jacobellis v. Ohio case on obscene material where Justice Potter Stewart wrote, “I know it when I see it.” Vague, absolutely, but still useful. It is the ‘feeling’ of failing. The stress towards the end of the sprint when the team knows they won’t get done what they struggled to (even less than what they originally wanted to). It’s the disheartenedness of the team when they slog into a retrospective no one wants to be at. It’s the guilt and grasping at causes; the looking for a place to put the blame. For those who do not have these feelings even when getting so little in their sprint completed, don’t worry we’ll come back to you.
As a side note, another aspect to failing a sprint is when you attempt to demo the product to the stakeholders and it doesn’t work. Yes, all of the items in the sprint were done so you may have technically finished the sprint successfully, but those items weren’t done right or are in some way defective. You may still get the feelings from earlier, and the consequences may still be the same. This means you cannot wash your hands of the sprint, caulk it up as a success, and move on until you are sure it is all done right.
So now we have a useful understanding of what failure is, lets talk about “What are the consequences for failing a sprint?” The first obvious one is a hit to moral, and a close second would be new corrections in processes. For example, if during the retrospective you discover that the estimation was completely wrong, you have to fix the process of estimating. Moving from the sprint level to the bigger picture can we think of bigger consequences? Project/timeline delays, changes in scope, and both of those come with costing money (often in resources or delay in profit). Those are all pretty abstract and not something the Scrum team often deals with personally (maybe the product owner). Let’s be honest though, no one is going to be fired from having a bad sprint, pay won’t be deducted, and I don’t think anything actually harmful will occur. And this is where my concerns for Scrum start to seep in. In my professional career, I’ve never received a good tangible answer of what the scrum team should care about when failing a sprint; no ‘real’ consequences.
That brings us to the final, and most important, question, “If there are little to no consequences, why do sprints matter?” Teams that routinely fail try to find ways around that failure and the feelings that come with it. Often teams become apathetic to the results. This could be the automatic moving of incomplete items to the next sprint, extending the sprint time, or other bad habits. This makes the timebox aspect of the sprint become pointless. When you do not suffer for the failure you are less likely to try to avoid the cause of that failure.
If your team has these kind of practices in place without the feeling of guilt, or without stress for trying to wrap-up every item, then this is what is wrong. As previously mentioned, there is no good answer to repercussions of failure. However, I also don’t think they are needed. As long as your team doesn’t roll over failed items, and as long as the team tries hard to figure out and fix the cause of the failure, you don’t need ‘punishment’. In other words, the problem isn’t the failure, it is the apathy to failure. That is what you should be combatting and what should get the ‘punishment’.
The proper way to deal with sprint failure is to take a hard look at your processes and fix them. It may mean putting less in each sprint while you figure out your estimation processes or figuring out a better way to decompose/architect large items so that they fit better in sprints. And frankly speaking, if the problem turns out to be the Scrum methodology and its timeboxing approach, then find what does work. For example, if you have a lot of critical items that keep appearing and inserted in the middle of your sprints, you may want to try out Kanban that deals with these critical items better. I personally implore teams to run a demo of the sprint goals during the Sprint Review meeting to help reinforce the promises the team made at the start. As malicious as it sounds, having a dev team stand in front of a stakeholder and admit failure helps ward off apathy and gets them to think a little harder next time about what they can promise. Again, the goal is not to punish the failure but to fix or prevent the apathy towards it.
As a general thought to sprints and Scrum, timeboxing has its benefits but doesn’t work for every team. As well, it works only when teams care about the deadline it creates. If your team doesn’t need or uses that deadline to motivate them review what your team needs and work with that.