#NoEstimates isn’t just about estimating

The #NoEstimates conversation is largely about estimating nowadays rather than NOT estimating.

Estimating, but in a probabilistic way. People often refer to this type of estimating as forecasting. Using cycle time. Throughput. Variance. Little’s Law. Monte Carlo.

All famously good stuff.

But I don’t want people thinking that’s all there is to the conversation. Many folks have interpreted it that way.

For me, larger questions remain. For example, is it possible, in certain situations, to deliver value to the customer at a rate which negates the need for doing any estimating at all, both up front and ongoing? Quick enough that they do not need to make any decisions or commitments based on anticipated delivery, only what was actually delivered?

Beyond whether this is possible or not in certain contexts, why might it actually be important or desirable to be in this state of not needing estimates? I can get away with not eating apples, but is it actually useful for me to not eat apples?

Well, the fact that estimates are usually needed implies that decisions and commitments of some form are made based on them. This is a common argument cited as to why estimating is immutable when working with customers in uncertain domains.

However, often the knock on effects of an initially inaccurate estimate are damaging financially or culturally. So I can imagine, in certain situations, it might be possible, and desirable, for the customer to ask for delivery of tiny working increments which can provide value for them right away and, explicitly, no estimates are asked for because doing so would create potentially irreversible knock on effects. Perhaps losing another customer’s trust by not meeting your “commitment” to them. Perhaps having to trash another project for which you had a team lined up to work on if things “went to schedule”.

I can imagine a few reasons why we might want to enter a working relationship in which we explicitly value the rapid delivery of added value over the anticipated delivery of value at some future point. Not to mention the trusted working relationship side of things. “Customer collaboration over contract negotiation”.

These are the broader questions I’m interested in. We get it, we can forecast with data to avoid deterministic estimation rituals and provide more solid, transparent estimates of when we will be done, or what will be done by when.

But can #NoEstimates thinking actually take us further? Into whole new ways of working with our stakeholders and customers?

Advertisements

6 thoughts on “#NoEstimates isn’t just about estimating”

  1. If you remove the “bad management” examples from the conversation, then discussion of how and when to estimate can be based on managerial financial principles. But to date, that separation has not been made.
    There may well be situations in which estimating in support of decision making may not be necessary. But when that discussion is clouded by misuse and abuse of estimates and the data they produce, it make it hard to reveal how and when value is available from the estimating process.

  2. A fixed cost and/or time, flexible scope type of project could work like this. We’ve done a few like that. We agree on a fixed budget with the customer, then continously deliver the most important things and adjust priority as we go in collaboration with the customer. When the customer is happy and/or the budget is reached, we stop. In this context estimates aren’t really needed (and we didn’t do them).

    Such a setup require quite high levels of trust between customer and supplier, and I guess that is the main reason this isn’t done more often.

    1. We have two “projects” in the portfolio with that setup – Fixed Cost and Fixed Period of Performance and variable scope.
      BUT, estimates used to make visible to the customer (a sovereign) what is the probability what features in the PBL will be or could be delivered inside the Time and Budget constraints.

  3. When working on a product for internal use / many customers rather than a project for a single customer, I think it’s entirely possible to ignore the estimates. Assuming that teams are delivering the most important features, and provided that costs to develop each feature do not vary too wildly, there’s no need for estimates IMHO.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s