Mar 082011

“You did not finish the stories you committed to!” a product owner at a client of mine recently raged against the team. “What the hell are you doing all day long? This commitment was pointless!” And he was right. The team commitment Scrum includes as part of the planning ritual is a dangerous practice that needs care — and committing on a certain number of stories or story points really is pointless. “Commitment” is one of these management buzzwords you have to use carefully. You should be very clear about what you commit on, what the appropriate tools to keep that commitment are, which tools are illegal, and what happens if you don’t keep the commitment.

To keep things straight: a self-organized team has to be committed to do a good job. The members have to be enthusiastic about what they want to reach; they have to take pride in their work and its effects on the customer. An agile team is not the place to train for a not-my-job award. So what is wrong with committing on the stories of a sprint?

Committing to certain stories or a number of story points is like a surgeon committing to a certain time period in which the patient recovers: you commit to something that is simply out of your control. If a team does not finish as many stories as it thought it would during the planning meeting, it just means that it has responded to change. The change may have been on the domain level, but most times the change is in the assumptions it made for the estimation. If a surgeon tells you that you will probably recover within seven days from a surgery, he or she assumes that you will not catch an infection with some awkward multiresistant bacteria that sends you to intensive care for three weeks. Still, infections like that happen. The Agile Manifesto tells us to value “Responding to change over following a plan,” so committing to a plan violates the agile values and is also not what Scrum suggests.

There is another element of planning in Scrum that is often underestimated: the sprint goal. The sprint goal is more abstract than the plan; it states some added value the team wants to provide to the user (or some other stake holder) with this sprint. The user stories planned for a sprint are just the best way to reach this goal as far as the team can tell at the time of the planning meeting. During the sprint, the team may discover better ways to reach that goal or it may learn that the intended way is not feasible, so it has to look for a different way. If you have to build a street from A to B and you find that building a German Autobahn is not feasible within the time frame, an unpaved country road may still help in reaching the sprint goal to provide a connection from A to B — although the initial user stories of entering and exiting a highway may no longer apply. These are the pragmatic solutions agile teams look for to maximize the project’s return on investment. These are the changes meant by the Agile Manifesto, rather than thinking, “Changing the plan is not my job.” As several Scrum trainers have assured me, it is the sprint goal the ritualized commitment during a sprint planning aims at, not the plan itself.

Committing to a plan not only violates the Agile Manifesto; it also undermines agile planning techniques: a core concept in agile planning is the velocity, the number of story points a team is actually able to deliver per sprint within its definition of done and with sustainable pace (i.e., without overtime). The way you determine the velocity is simply by watching yesterday’s weather, the number of points the team finished in the last (few) sprint(s). If the team commits to a certain set of stories and finds change, it has only two options to keep its commitment: overtime and reduced quality. Does that sound familiar to you? It should, because this is the plague with fixed-price-fixed-scope projects agile wants to get rid of. Even worse: this type of commitment increases the perceived velocity, putting more pressure on the next sprint and starting a vicious circle of eroding quality and unrealistic expectations. Committing on a sprint goal forces the team to cut on the scope instead of quality.

There’s another question you can raise here: Do I need that explicit commitment on the sprint goal, anyhow? After all, the team is either committed to the endeavor — in which case it doesn’t need a ritualized commitment at each planning meeting — or it isn’t — in which case you won’t solve your problem with another ritual. Most Scrum trainers I’ve asked this question gave a clear answer: “The commitment is a core element of Scrum. If you skip it you’re not doing Scrum anymore.” That’s a clear message. If complying to Scrum is not as important to you as it is to certified trainers, you may find that the explicit commitment may help especially some inexperienced teams to understand the concept of a sprint goal. You may also find experienced teams that like the commitment and stick to it and others that do great work without this particular ritual. So, my personal advice here is to ask the team what it prefers, to encourage the team to inspect the effect of its current practice critically, and to adapt according to its findings.


Jens Coldewey

Jens Coldewey, based in Munich, Germany, is a Senior Consultant with Cutter's Agile Product & Project Management Practice. He specializes in deploying agile development and object-oriented techniques in large organizations.


  5 Responses to “Committing to Commitment in Agile Teams”

  1. I like the article, it described how I think about commitments also.

    I have seen organisations where they link the bonus system to the commitments… an horrible situation. Teams only do work if they receive story points, and almost refuse to do anything that brings their commitment in danger…

    “The commitment is a core element of Scrum. If you skip it you’re not doing Scrum anymore.”… duh…who are they to determine if you do Scrum… Scrum it self is not a goal.

    I also believe the sprint goal is often undervalued. A goal is important for a team. Of course the goal should not be an exact summary of all the unit stories…

    Good article!

  2. One thing that may be missing from this description is that commitment (as I’ve used it and as I understand it described in Mike Cohn’s work*) is a process, not a destination. The goal is not the commitment itself but the discussion that comes out of why we feel comfortable committing to each incremental list of stories.

    Typically on my projects we plan sprints by adding a number of stories to the Sprint backlog. Does the team feel like we can commit to getting that amount of work done? Yes, let’s add another story. No, then we stop adding stories and re-evaluate the list. We use it as a metric to see how much we can fit — our velocity number also being a guide.

    Often during iterations as new information is presented we will address it and change the plan. We don’t see the commitment as a contract, it is just how we decided what goes in. Perhaps looking at things this way, commitment during Sprint planning will feel well aligned to the manifesto.

    * See:

    • Brian,
      thanks for your comment. I think you did a direct hit: Whether a commitment is helpful or not is a matter of how the team deals with it. As your post sounds, your team found a good way to use the commitment. Still, most teams we encounter show way less healthy interpretations. Hence I still subscribe to the Scrum Alliance’s decision to get rid of the commitment, though teams that found it being helpful can still use it.

  3. […] projects require commitment from the project members. While this type of commitment has a special context, it still contributes to the building of a strong team, especially in combination with other agile […]

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>