Against Estimate-Commitment

The Estimate-Commitment relationship stands in opposition to collaboration. It works against collaboration. It supports conflict, not teamwork.

Somewhere in our conversation, Steve supported estimates with a story of a Scrum Product Owner who wanted it all, and who kept adding things, and Steve’s people found it necessary to use estimates to show that things had to be removed, almost a return to a change control mechanism.

The Product Owner is responsible for maximizing the value of the work done.

I replied immediately with the suggestion that the relationship between the Product Owner and team was not the one recommended by Scrum. The “I want it all and you guys have to do it for me” Scrum pathology is quite common. To a large degree, it comes about because the relationship between the Product Owner and the team is in the Estimate-Commitment style, not a collaborative partnership style.

Scrum makes it crystal clear¹ that the Product Owner is responsible for maximizing the value of the work done. That doesn’t mean that the Product Owner should be treated like a god and allowed to run the project into the ground if they want to. Everyone should still responsibly guide them, inform them, and so on. This guidance often includes helping the Product Owner see that there is too much to do.

Estimates not required

We don’t need estimates to help the PO see how much there is to do. The CIO of Chrysler perfectly understood “This is our stack of story cards. Every month, we’ll show you how many are done and how many are left to do. If you don’t like the way it looks, you should terminate the project.”²

When we do as Scrum demands, and hold the Product Owner solely accountable for delivering the best possible product by the due date, we move away from the unbalanced Estimation-Commitment relationship. We move off the “we-they” axis and begin to create an “us” axis. Our approach to prediction and tracking needs to support the “us” axis, not oppose it.

In a Scrum / Agile shop, the Product Owner is responsible for deciding what to build next, every couple of weeks. The Dev Team builds it, delivering ready-to-ship increments, every couple of weeks. It is the Product Owner’s choices that determine what the product will contain, and how fully-fledged each feature area will be. The Product Owner steers the project to success. This is exactly not Estimate-Commitment. It is not “we-they”. This is true customer-developer collaboration.

How might we collaborate?

As we talked about in the previous article, this won’t happen magically. Better estimation seems possibly helpful, but its effect is to improve along the Estimate-Commitment axis, which is harmful to the Collaboration axis.

We could estimate …

We do need to project how much can be done, and one way to do that is to estimate. We could look at each feature area, break them down as much as we need to, associate some kind of estimate with them. Again, having done this, it’s almost impossible to resist turning these estimates into commitments. And that is harmful to the team’s collaboration.

… but we need not.

However, there’s no need to estimate. There are completely reasonable alternatives. Everything we do in Scrum has to be at least small enough to fit into a two-week Sprint. Most teams have discovered that two days per backlog item is a better size. Either way, it’s pretty easy for a reasonably experienced team to talk about backlog items and assess whether they’re small enough, or not.

As soon as we start delivering ready-to-ship software³, we establish a cycle time for stories. We can work numbers on that if we wish. In practice, the team and Product Owner build up such a strong and deep understanding of how big things are and how long they take that they find it easy to decide what to do next and what to defer. Counting the stories works. Simple burn-up charts work.

Transform the model

Agile, if people will actually do it, transforms the Estimate-Commitment model, which is fundamentally about contract negotiation, into a truly collaborative stream of building up the product incrementally. #NoEstimates, by working to find alternatives to estimation, is helping to bring about this transformation, creating a real team and moving toward collaboration instead of contract negotiation. This is truly different, and it’s directly in line with the Manifesto’s values.

On the contrary, we all support good collaboration. Better estimates don’t necessarily lead to misuse of commitment, and do not therefore always militate against good collaboration⁴

I answer that our esteemed interlocutor himself said that “Commitments are here to stay: good estimation supports the commitment process.”

While it is possible to use estimates without interfering with collaboration, it is extremely dangerous. As such, alternatives to estimation should be tried first, and only if they fail to work should we turn to estimation.

Collaborate, don’t estimate.

Agile is a team model, not a we-they model. Agile is a collaboration model, not a contract model. It’s really different. Organizations really do this. Many organizations really do this.

Many more, of course, do not. They never even try. Don’t be that team.