I respect Mike Cohn a lot, but the idea that we need to separate estimates from commitments doesn’t add up. On one hand, I can’t commit so here’s my estimate. Okay that makes sense, but then on the other hand, if I increase what I can’t commit to - my estimate - I can increase it by a factor of X and then all of a sudden we can commit. That doesn’t seem likely.

The future is too unpredictable. The farther out we’re estimating the more error prone our estimates are going to be. Simply extending our estimates so we can give a guaranteed commitment will sound nice to product owners and the like, but it’s not going to make it true.

Most product owners would rather have the commitment any ways. In my experience they don’t care about a estimate of 6 - 8 months if you also are going to give them a commitment of 9 months. Just tell them 9 months. They’ll be happier in the long run (especially when it’s not done at 6 months). But if we end up giving a commitment, what’s the point of utilizing the estimates beyond coming up with that commitment? And if the commitment ends up being the important piece of information doesn’t that put us back to square one anyways?

Keeping track of both estimates and commitments seems counter-intuitive, you either can anticipate the future and the complexities surrounding the software you’re building or you can’t. It doesn’t make sense to have it both ways. Saying so otherwise seems like pretending.