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:
-
How curiosity can improve your project estimates
-
Everything you need to know about project scope
-
3 Fundamental rules project managers should use when planning
