Scrum: No Commitment Required!

A couple of years ago I first talked about applying the decoupling principle to Scrum. Since then I've turned a bunch of that material into a presentation called “Scrum and Kanban Like Chocolate and Peanut Butter.” I’ve made many updates to the presentation and presented it to a wide variety of audiences. One of the main points of the presentation is that all of the things in Scrum that are coupled to iterations can be defined in such a way that they are no longer coupled to iterations. I argue that once you have done that with everything, there is really no value left in an anchor point which anchors nothing. That is, there is no fundamental need for iterations in Scrum.

From time to time I’ve realized that I forgot to decouple something, figured it out, and added it to the presentation. For example, burndown charts, burnup charts, and per-story timeboxes. The per-story timeboxes were tricky to even notice because in Scrum we generally think of timeboxing at the iteration level, but in effect that also imposes a timebox on individual stories. If you remove iterations without taking this into account then you are also removing the per-story timeboxes.

But recently, buried among the many feedback forms from presenting at Agile 2011, I found three little words: “What about commitment?” Ouch. I had missed a big one! The Scrum team makes a commitment that is tied to an iteration. How could I have missed that?

As I thought about it more, I realized that I do actually address this point in an off-hand way when talking about decoupling story assignment from iterations. However, I am very grateful for the comment. It helped me realize that I had been effectively dismissing commitment as though breaking a promise with a shrug.

Scrum's Commitment

It turns out that Scrum's commitment is a bit too strict. Even the version of the Official Scrum Guide as revised by Ken Schwaber and Jeff Sutherland, the co-creators of Scrum acknowledges this. In the new version of the Scrum Guide, the commitment has been replaced with a forecast. The idea is that the forecast represents the combination of what the product owner wants and what the team believes it can deliver as the next shippable increment. This is a reasonable response, but I think something is lost in the change. Let's look at this another way.

Mutual Trust

The original idea behind Scrum's commitment is that the team commits to finishing what they have signed up for for the sprint and everybody else commits to leaving the team alone. It is really two commitments based on mutual trust. Without this mutual trust, both commitments break down. But both commitments are actually completely unreasonable and don't reflect reality. The goal is good, but the implementation is poor.

The problem is that the team is not prophetic. They can't possibly know how the work will turn out until they have actually attempted it. More often than not, their estimates will be wrong. Sometimes a little, sometimes a lot. Things happen. The product owner is not prophetic either. They can't possibly know what demands of the business will come up or how customer needs may change within the timeframe of a sprint. A set in stone commitment makes it difficult for both parties.

In practice, the most important ingredient is mutual trust between the team and the product owner. This rapport allows the team to go to the product owner when they discover they have made an unrealistic promise and ask to switch out a story. It also allows the product owner to come to the team with a new request that is more important than another unstarted story and ask to swap them.

Decoupling the Forecast

If Scrum now talks about a forecast, and we are comfortable with the transition of commitment to mutual trust, then the real question is how do we decouple the forecast from iterations? First of all, ask yourself if you need it. If you don't, then there's nothing left to do.

On the other hand, if you feel the need for a forecast then the same approach can be used as for decoupling other aspects of Scrum, you simply redefine the timeframe. By default, the forecast is tied to the timeframe of the iteration. If your iteration is currently 2 weeks long, then go ahead and provide a two week forecast. It is a subtle point, but by defining a forecast period on its own, it is no longer tied to your iteration length. For instance, you may be doing four week iterations and then move to two week iterations. But if you decouple the forecast from the iteration then you can keep your four week forecast. And once again, after you have decoupled everything in Scrum from iterations, what's the value of an anchor point that has nothing anchored to it?

You may also be interested in the follow-up to this post, "Sticking to Estimates"