“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.