A Principle for When Not to Estimate

Based on a prior post, I was ‘asked’ to extract this into a generalized principle. (I invite you to read that in full, so you understand the context.)

Of course, one has to open your mind that the value of estimating has to be questioned in this circumstance and what you are trying to accomplish with estimates and how they may or may not contribute to your work. And I would be remiss not to mention 3 things:

  1. My push on the #noestimates tag is not one of #neverestimate; on the contrary, I am interested in circumstances where estimation may need to improve OR it may need to be ditched to increase value production. I would never advocate to never estimate under all circumstances, yet at times estimation may be wasteful and should be eliminated. Depending on risk understanding, one may absolutely need to estimate. The more potential (in terms of probability and impact) for loss of life or loss of money, the more need to estimate. I do have a keen interest in when estimation may not be needed though beyond just dropping story points.
  2. If you decide to apply this principle, also determine the circumstances and how you would detect that perhaps this principle doesn’t apply in your context. Ask yourself, how does this apply? What will tell me whether I applied it incorrectly, and lastly what possible paths should I take to rectify the situation?
  3. Lastly, this whole set of arguments or debate is very binary. (I’ve only ever seen actual dialog on the topic at Agile Dialogs.) #nobinary is something I advocate on a variety of subjects and you can learn more about how to drop binary thinking and contribute to interventions at Agile Brambles (an evolving site). If your mindset is one where you only see your point of view, then you may find thinking through the paths on the site fruitful.

OK, onto the principle….

When the estimate is not going to be used, regardless of how quickly you can produce it, don’t create one.

Looking back at my context briefly, the old way was to estimate all work that came in and then regardless of the answer, we did the work.  This delayed the start of the work and actually digging into really understanding it by doing it. It doesn’t matter whether you are using a super sophisticated model or a simple guess. In my case it at a minimum delayed work by a week and in some cases more. From a any form of value production standpoint (like weighted shorted job first), the estimation part of the process was hurting the organization. I’m certain many of us can think of times when an estimate wasn’t used and really had no intention of being used.

Be sure though that it truly will not be used. This is important. If this is the case, then it has some degree of importance and then the level of accuracy and precision should be quickly assessed and the estimate done at that level. This brings us to a corollary:

Only estimate at the level of accuracy and precision required (or that has no incremental cost above what is required).

Often estimation takes time and effort. When estimation is needed to understand risk, then only do it at the level required OR if you can do it more accurately/precisely with no additional effort, then go ahead and do it the higher level. This also goes into thinking about creating sophisticated models or simulations that may be used. Bring these in when the situation warrants it, a good prioritized backlog of work, projects, etc. will reveal whether there may be a future for using one.

You may notice that both of these boil down to –

Simplicity — the art of maximizing the amount of work not done — is essential.

Hmmmm… I’ve seen that before.

One last principle:

Question whether this principle (or its corollary) continues to apply.

You may have determined you needed an estimate or perhaps you determined that it wasn’t needed; be sure this still remains true on a periodic basis.

I’ll close, ‘anecdotal’ circumstances are evidence. If you find that you don’t need to estimate under some circumstance, then that is a set of evidence showing a different reality. It’s very similar to observations made by Galileo and Copernicus that indicated that a geocentric view was incorrect and a heliocentric view was more accurate. Or perhaps an even better metaphor would be when Einstein was able to explain observations being made through relativity theory. It didn’t negate how classical mechanics worked under most circumstances, but there were circumstances (context) when mechanics needed to be replaced. If we never examined observations (anectdotes), then everything would remain status quo.

2 thoughts on “A Principle for When Not to Estimate

  1. Let’s start with the definition of a principle.

    “a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.” Or “a comprehensive and fundamental law, doctrine, or assumption.”

    Then on to the original conjecture for No Estimates.

    “#Noestimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, to make decision with “No estimates”

    I’ll add some clarity to Woody’s conjecture. The domains of software development operate in the presence of uncertainty. Uncertainty comes in two forms – reducible (Epistemic), with probabilistic processes and irreducible (Aleatory) with statistical processes. Estimates are needed to manage the risks created by these uncertainties. Those risks – reducible and irreducible – must be addressed during the decision making process as part of any management principle.

    As Tim Lister tells us “Risk management is how Adults manage projects.”

    So if we’re going to be adults when managing projects – especially with other people’s money – we need to manage risk. And to manage risk we need to make estimates to reduce, mitigate, or transfer those risk.

    The only risk handling response that does not require making estimating is to IGNORE the risk. So it may be a principle of No Estimates when making decisions to IGNORE the risk.

    So let’s look at the “principles” you mention. First these sound like practices rather than principles, given the definition of a Principle.

    1. When the estimate is not going to be used, regardless of how quickly you can produce it, don’t create one.

    If you’re not going to use ANYTHING don’t do it. This is about business management not about NOT Estimating.

    2. Only estimate at the level of accuracy and precision required (or that has no incremental cost above what is required).

    ALL good estimating guidance starts with the “value at risk,: What’s the cost of the estimate versus the payback for that estimate in terms of reducing risk. Standard estimating principles apply here. Don’t invest more than you intend to get back.

    So this is a practice about making estimates. Not clear how it applies to NOT estimating.

    3. Simplicity — the art of maximizing the amount of work not done — is essential.

    This is a Systems Engineering principle (see http://www.incose.org) , but you need units of measure to make that happen – effectiveness and performance as a good start. ROI on ANYTHING you do is core business principle. And that ROI is operating in the presence of uncertainty for any non-trivial project. So we’re back to estimating needed to make decisions.

    4. Question whether this principle (or its corollary) continues to apply.

    This is common mantra of the #Noestimates community. Question what? Question the governance of the business? Governance is about decision rights (https://www.amazon.com/Governance-Performers-Decision-Superior-Results/dp/1591392535 ).

    Do you have the right to question how budgeting and spending is done at your firm? Do you have the right to NOT provide estimates to those paying for the cost to develop the value produced from that expenditure? It ain’t your money. If it is, spend as you wish no one cares.

    So your “principles” are actually good practices for making decision in the presence of uncertainty. Not principles for NOT estimating.

    A principle is Immutable (at least within a domain). E.G. The principles of Risk Management or the Principles of thermodynamics, or the principles of compressible fluid flow over the wings of your A-7. Along with your practices comes some processes. For HOW those practices are put into practice.

    A principle of estimating starts with the principles of Microeconomics of Decision making in the presence of uncertainty.

    Your practices and the process that implement them are likely applicable across the board. But those practices are “informed” by the principles of Microeconomics, Managerial Finance, and Business Governance.

    So here’s the unanswered question for those conjecturing No Estimates is applicable outside their personal anecdotal domain.

    By what PRINCIPLE can you make a decision in the presence of uncertainty WITHOUT estimating. Let’s hear what NE has to say for that?

    Perhaps a read of the materials in Section 6 will provide insight into the World View of those of us applying agile to Software Intensive System of Systems http://www.slideshare.net/galleman/agileevm-bibliography-v2

    Your domain may be much different than the broader domains where governance is the basis of decision making. I’d suggest the practice and processes may also be different, but the Principles of making decisions in the presence of uncertainty requires estimating the impact of those decisions no matter the domain ‒ hence the Principle informs your practices and processes.

    Like

    Reply
  2. Thanks for responding…

    Merriam-Webster has as its #2 definition for principle as “a fundamental source or basis of something”. If we used your #1 definition, there is no Lean or Agile principle that would equal a principle as when we talk about ways of working there are no absolutes. Your second definition is a bit closer, though the word comprehensive doesn’t seem to fit; again that would assume context does not matter.

    I find most of your points hinge on that everything about a task, story, project, program, etc. is estimable and since it is estimable in some manner, it must be estimated. This appears to be an assumption; just because something can be estimated does not mean it must be estimated. And just because it can be ignored, doesn’t mean it shoudl be ignored (that’s the counter argument). My fundamental basis (principle) for not estimating is knowing whether the estimate will be used or not.

    For the Govt example I provided, the estimate was never used. I suppose it could have, but the fact that once it was handed over from the contractor and it was never used made it simple. Let’s skip the time and effort (and money) in creating a non-value added deliverable. (BTW, nothing contractually said we needed this estimate). So as the COR, I eradicated that step out of my process.

    And as a general principle, I think if a deliverable isn’t going to be used – truly not used, then don’t create it. And even if you decide it is not necessary now, it could come back to being needed, so reflect on occasion whether you need it. Would you really want to do something that isn’t necessary? That said, and I have never disputed you assertion, I do believe in your domain of military and similar systems, you need estimates. You need them to determine budgets, to understand risk, and to level set needed performance. Some of this could be done in other ways. I could set I am willing to see how far you can get on $X (this is somewhat how venture capital or a SBIR* works); at that point I will see whether it what you achieved warrants more money and perhaps ask for an estimate at that point. And I may want to stick with estimating that budget amount or using your estimate or doing both (which is the case for most Govt contracts).

    *SBIRS do request an estimate from the contractor, but the fact of the matter, there is a fixed expectation of money per contractor that comes from a fixed pot. If I put out a SBIR proposal and got 12 bids and all were over my expected amount (which is not estimated BTW, it’s a rule of thumb amount per phase (I or II)), then I would step back and either not pursue it any longer or drop some scope and put it out for bid again and see if I get bids that fall within the zone. Part of the reason SBIRS get away with getting a lot for the money is that the contractor owns all the rights to the product; the military just wants it in the marketplace.

    Cheers and thanks for the thoughtful response…
    Paul

    Like

    Reply

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