Does #noestimates really mean no estimates?

When I learned more about the #noestimates movement, primarily through articles authored by Woody Zuill, Neil Killick, and Ronald Jeffries, I was really intrigued. I have yet to manage a project portfolio where no one has asked, “What is the target date?” or “I want you to share your budget variance every month.” After all, it would be fabulous if I could enjoy the whooshing sound deadlines make as they go by because the organization has no concerns about cash flow. 

I agree with what I interpret to be the basic premise of #noestimates: estimates are only as good as the requirement or story being estimated. If the requirement is vague, so will the associated estimate be. Why spend time estimating, when that time could be spent building a solution instead? I am adding my voice to the #noestimates school of thought.

Teams are estimating when they use their judgment to predict development efforts, use modeling to forecast schedules, develop predictive models, pull data from previous projects, or use rules of thumb.

While #noestimates is explicitly for software development, there is usually more than software development going on in a project portfolio, even at software development companies. Working completely without estimates seems possible in high-performing, mature, self-funded organizations that have very stable systems and processes. I find that stakeholders, especially those providing funding, want some idea of what they are getting in return for their investment. “Working software” can be produced outside the context of good design or overall architecture, where the trade-off is higher levels of maintenance activity, less extensible and scalable results, or technical debt. Is your organization ready for that? 

Funded pilots with no defined scope may be frequently found in mature agile organizations, where funding is obtained without supporting estimates because the underlying budget practices are based on resources, not projects. #noestimates is perfectly suited for solution delivery efforts where the expected result is not known or clear, when the result is produced in a dynamic environment, or when predictability is not possible or not expected. It is infinitely more effective in organizations characterized by learning and trust, where their customers have a high tolerance for change and the accompanying high levels of communication. 

In my estimating experience, the key is to right-size the amount of time spent estimating to keep it commensurate with the organization’s culture and project portfolio environment. A shared understanding of the desired results, combined with a willingness to focus and prioritize, is more powerful than the estimates themselves. The discussion around estimates is more important than the effort to develop the estimate. A team’s collective experience, when discussed and shared, results in accurate estimates in minutes. It is a myth that estimates become more accurate; the more time you spend estimating. 

1 2Next page

One Comment

  1. All projects, from agile software to nuclear power plant construction to flying to Mars, operate in the presence of uncertainty (I work in all those and many more domains). These uncertainties create risk to the cost, schedule, and technical performance of the project
    There are only two types of uncertainty
    – Reducible (Epistemics), which are “handled” through direct actions on the project to “reduce” the risks.
    – Irreducible (Aleatory), which are “handled” by margin. Cost margin, schedule, margin, technical margin
    The #NoEstimates advocates appear to not understand this immutable principle of “managing in the presence of uncertainty. Here’s a start
    Next, the #NoEstimates advocates, assume – wrongly – that it’s their money and they can spend it as they please.
    It’s NOT their money. Those paying them to produce value in exchange for the cost of producing that value (a paycheck) have a fiduciary responsibility to those “governing” the project or the firm to have some understanding of how much will it cost, when they will be done and what will be produced by expenditure of money and passage of time.
    No Estimates advocates ignore these principles – possibly willfully ignore these principles.
    The “cost” of the estimate can be determined by the “Value at Risk” – another concept ignored by NE advocates.
    Google “value at risk in IT projects” to see how this works with “real options”
    For more information on how to manage in the presence of uncertainty please see the compendium of writings at

    For resources on estimating see

    And you too may come to the same conclusion as Alistair Cockburn (an Agile Manifesto)_ attendee that NE is a Hoax

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button