The three harms of ceremonial commitment in scrum. A rant.

The term Commitment was removed from The Scrum Guide (pdf) and replaced by the term Forecast back in 2011. Here is my rant against the concept of commitment as it is still used by many otherwise agile teams. If you don't do scrum, but any other development method that ties a fixed set of development tasks to an iteration, then this article is also for you. You must not mistake ceremonial commitment with the commitment of individuals and teams to deliver excellent work. We all agree the latter is a great and desirable thing. In this article I am only talking about the former.

Sprint commitment means, that a team of software developers have to commit to finishing a fixed number of stories in the next iteration. I guess the hope often is, that due to the pressure created by such a commitment more stories are developed per time unit. I also heard the reasoning commitment would improve planability of a development project or that it increases the motivation of developers. I think that is all wrong.

There is three main reasons why I think the ceremonial commitment is a harmful concept. Let's dub them the three harms of sprint commitment.

Harm 1: Lowering the mood

Commitment is based on the team's estimation of stories. Those estimations are, well, only estimations and it is quite probable they are imprecise if not plain wrong. Often enough this is reason enough to give a negative feedback to an otherwise great team. This ignores the fact that any estimation is imprecise no matter how good a team is.

Here is what happens for two example teams:

• Team A thinks it can finish 7 Stories in a sprint. In the end it manages to finish 5. The 5 finished stories are of high quality and add great value to the software.
• Team B thinks it can finish 7 Stories in a sprint. It makes a commitment to those stories. In the end the team manages to finish 5. The 5 finished stories are of high quality and add great value to the software. The team missed its sprint goal. The sprint is counted as a failure.

The result: Team A and Team B did the same great work. Team A is a happy team and starts the next sprint with verve. Team B is an increasingly frustrated team and it starts the next sprint downheartedly. The reason is negative feedback due to sprint commitment.

Harm 2: Lowering software quality

Commitment makes developers sacrifice software quality by making them hurry to finish their stories at the end of the sprint. The commitment makes the end of the Sprint an artificial barrier. Developers will be tempted to speed up development in order to finish a stories they committed to.

There is only a few ways to reach short-term increase of development speed. Here are two of them:

• Working overhours. This strategy will not win you a price. Though it might help in the short-term, this will harm the long-term performance of a developer. Done excessively it will harm the developers' health. Fortunately this is something we do not do at Otto.
• Accepting lower quality. Reduce your coding standards. Omit writing unit tests. Go for the quick and dirty solution. Leave refactorings for later etc.. This way you create an increasing pile of technical debt. You create harder to change code so you decrease your future velocity. An additional psychological effect is that developers that find code of low quality will be inclined to produce low quality code themselves. Your may find your team in a downwards spiral. See broken windows theory for details.

In our little example It looks like this:

• Team A thinks it can finish 7 Stories in a sprint. In the end it manages to finish 5. The 5 finished stories are of high quality and add great value to the software.
• Team B thinks it can finish 7 Stories in a sprint. It makes a commitment to those stories. At the end of the sprint fear arises the commitment might not be met. The team hurries to deliver all stories it committed to. The stories are of less than usual quality.

The result: Team A can work on with the usual speed. Team B is from now on hindered by the technical debt it created. The reason is pressure created through commitment.

Harm 3: An artificial QA bottleneck

In our sprints we frequently observe one thing: At the end of the sprint we put a lot of pressure on hurrying stories through QA and signoff steps. In this time of the sprint test-manager and product-owner become a bottleneck. This is annoying for everyone involved. And it is also a direct effect of ceremonial sprint commitment. If we would just finish the stories when they are done, QA work would be much more evenly distributed over the time. This helps to utilize the, usually limited, QA resources much better. This phenomenon has been discussed in depth in the Kanban community.

Let's have a look at our two teams again:

• Team A thinks it can finish 7 Stories in a sprint. In the end it manages to finish 5. The 5 finished stories are of high quality and add great value to the software. The next two stories are handed over to QA in the next sprint. When they are ready for it.
• Team B thinks it can finish 7 Stories in a sprint. It makes a commitment to 7 stories. At the end of the sprint the team hurries to deliver all stories it committed to. The QA gets many stories handed over on the last few days of the sprint.

The result: The test-manager of Team A is happily working on one story at a time. In Team B the test-manager has to test many stories at once at the end of the sprint. The QA becomes a bottleneck. As stories are waiting to be tested, bugs are detected lately when the developers are already working on something else. This makes bug fixing more expensive. The reason is an artificial accumulation of finished stories created by commitment.

But what about forecasting?

If you want a forecasting tool, you have one right in your hand: The team's velocity in the past. Just average the last few sprints' results and you can give a rough estimation of what the team can deliver in the future. If you are careful and assume only e.g. 80 percent of that velocity for future sprints, you can give a quite good prediction of when certain features will be available to the customer. There is no precise prediction of the future in agile projects. This is a fact you have to accept. If you can not accept that, you can not work agile. Good look finding a non agile development method that does that for you.

By the way: If you want to know whether or not the work you are doing speeds up, whether you are accelerating or decelerating, you can obviously use the velocity as well.

So are sprints any good then?

Yes they are! Sprints offer a rhythm for our work. They help synchronize collaborating development teams. Sprints help to have retrospective meetings to look back on your work on a regular basis. They help measuring the velocity and so allow for an as-good-as-possible prediction of team progress. If you do not do continuous deployment they offer a friendly reminder to deploy to the production system at least once every few weeks.

While sprints have a value of their own, it might still be a valid idea to go without sprints completely and just do continuous everything. I'd love to try that sometime. But that's another story which is told at the campfires of the nice and friendly land of Kanban.

What's the lesson?

Do you do still do scrum with a commitment? Do you consider a sprint failed that did not meet that commitment? Do you have a fixed set of tasks for your development iterations?

Let me say it with a little joke that Kevlin Henney told in the context of shared mutable state It is of universal wisdom:

Patient: "Doctor, Doctor, whenever I do this, it hurts." Doctor: "Then stop doing that".

How about you?

Now you know my opinion about commitment and it did not get off lightly. Do you agree with me? What is your experience with sprint commitment? Does it work for you? Do you even love it? Leave a comment below. I am curious about your opinion.