I was at Agile Open Toronto as week ago and this post is a short report and a follow-up on the “No-Estimates” session that took place there. The session was proposed and led by Chris Chapman and 23 people, about one-fourth of all open-space attendees showed up for it.

I believe Chris’ proposal was motivated in large part by Woody Zuill‘s story of no-estimates. Check out also Woody’s story of Mob Programming, a novel collaboration technique that is important part of his system.

The start of the discussion was uninspiring as we recycled often-cited notions such as:

• Estimates are fragile, they are really “guesstimates.”
• Not reliable if the timeframe is longer than one month. (Yeah, right, like all Scrum teams always meet their two-week sprint commitments.)
• More spin of “guesstimates” such as “wild-eyed guesses.”
• Estimates are useless, but the process of estimation is useful to the team. (So, what prevents the team to discover that useful knowledge without an exercise aimed at producing a useless number?)
• There is value in team’s talking about each story. (What? They are not talking about it otherwise and on any other occasions?)
• Correlation between the team’s cohesion and the quality of its estimates. A reasonable objection, which didn’t stand scrutiny.

Understanding It Deeper

The discussion eventually reached the point when some people started talking about deeper issues surrounding estimation. This is when I think the session became really valuable to the participants.

Trust. Estimation correlates with a low-trust culture. In a higher-trust organization, estimating the time to carry out this activity or that quickly loses its value. Business stakeholders can make decisions on what products and features to pursue based on their prudent assessments of risks and value, and they are trusted to do that. At the same time, technologists put their best effort behind the few most-valuable products and features. Frequent delivery, continual “doneness” help maintain trust. Trust enables all people involved to understand together that effort estimates have little correlation with delivery lead times and that “the time it takes” is never a number, but a probability distribution.

Decision-making. Effort estimation is pervasive in the software industry because it is assumed if only we could obtain an accurate enough number, we could accurately calculate ROI, prioritize backlogs, make good promises to customers, etc. However, “just give me the number” hides the reality that what we really need is not numbers, but decisions. Decisions on what to work on and in what sequence. How many bits of information do we need to make a decision? What information about the value of a new feature, or a bug fix, or associated risks is already available? When people start pondering such questions, it often turns out a lot of such information is already available and a precise effort estimate adds little to the decision. On the other hand, “just give me a number” often hides weak understanding of other factors involved in the decision and a weak decision-making capability.

Sizing features. T-shirt sizing was cited during the discussion as a way to estimate features on the order of magnitude and thus provide some useful bits of information to the decision-making process. It was quickly noted that T-shirts are not a great way to communicate the difference is sizes and the lizard-based scale may be better for it. One of the participants had an example how in her small software company, the development team established a steady delivery of iguana-sized features. The business stakeholders no longer need to ask the product developers to estimate each “iguana”, but instead, analyze risks, experiment to understand market value, and choose which iguana to work on, connecting the decision to the economic outcomes. They may even take a risk on an occasional Komodo dragon!

We didn’t get into exposing ROI as a vanity metric and into what specific risk management techniques can be used in place of the deterministic estimates. So, to finish the post, I’d like to summarize some of the most common well-established approaches that have been put in practice by the Kanban community with great success in recent years.

• Make the value creation process explicit. This is no trivial matter – most Kanban boards are different, most Scrum boards are the same.
• Establish a reliable delivery cadence that is economically sensible and helps maintain trust.
• Make the commitment point explicit. Hint: if “backlog grooming” is part of your vocabulary, you don’t have an explicit commitment point.
• Limit work in progress, which has the effect of transferring information and risk management upstream.
• Treat everything upstream of the commitment point as an option. Options have value, options expire, don’t commit too early unless you know why.
• Improve not only the production capability, but also the capabilities to replenish options and select and sequence commitments.