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. 

The team should develop a collective response to questions like, “How much will it cost?,” “How long will it take?,” and “I need Y by X date; can you do that?”  If a team does not have a learning culture or support from the top, the collective response from a #noestimates perspective could be labeled as a performance issue, especially when those questions are voiced by people higher in the organization than the people expected to answer the question. 

What are your thoughts? Is developing an estimate always an expense? If so, reducing the time to develop an estimate to as close to zero as possible is the right thing to do. Do you create estimates, or support modeling the work required to produce a result (also known as a work breakdown structure or plan)? Is your team always working on the most valuable result, and ready to ship that result today?

 

Similar Content:

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
    https://www.slideshare.net/galleman/risk-management-denver-pm
    https://www.slideshare.net/galleman/managing-in-the-presence-of-uncertainty
    https://www.slideshare.net/galleman/managing-in-the-presence-of-uncertanty
    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
    https://herdingcats.typepad.com/my_weblog/2019/04/the-collected-works-to-increase-the-probabilty-of-project-success.html

    For resources on estimating see
    https://herdingcats.typepad.com/my_weblog/2019/05/software-estimating-resoruces-1.html

    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
0
Close
Close