#NoEstimates reimagines the classic approach to securing funding with a combination of budgeting and a “value to actual cost” feedback loop. Classically an estimate for a project or product is established at the beginning of work and refined periodically. That estimate is an approximation of the cost of work (component, project, product) based on what is known and extrapolated into the future.  #NoEstimates envisions an environment in which work continues as long as the value outweighs the cost (including opportunity costs).

The dictionary box on Google defines an estimate as an approximate calculation or judgment of the value, number, quantity, or extent of something. The dictionary definition is great, except in a software development environment where an estimate is generally conflated with a promise, a guarantee, or a price.  The estimate becomes a certainty rather than an approximation. The Nobel Laureate, Kenneth Arrow stated;

“Vast ills have followed a belief in certainty.”  Kenneth Arrow

Software development, in all of its varied forms, is always complicated (hard to understand but can be predicted) and often times, a complex (an outcome is not perfectly predictable based on the known or measured inputs) endeavor. Complex systems are not predictable. The inability to promise what the cost will be to develop complex solutions combined with pay and incentive systems that demand certainty (those demands generate all sorts of problems) stoke the #NoEstimates movement.

Woody Zuill originated the use of  #NoEstimates, he tracks his use back to a blog entry he wrote in December 2012. The tweet

#NoEstimates – I’ve added a little more fuel to the fire:
(link: http://bit.ly/NoEstimatesIntro)


Vasco Durate peels back both the curtain of time and Twitter declaring an earlier birth of the concept in a presentation in January 2012.  His first talk on NoEstimates was in Jan 2012:


The use of a #NoEstimate approach requires teams or organizations to break work into smaller chunks, to do the highest value work first, gather feedback and then to determine what to do next using the amount of value being delivered as a governor on the team’s throttle.

Special thanks to Allan Kelly, Vasco Duarte, and Woody Zuill for the history of #NoEstimates!

Note: This is the second piece for a project I am doing with Ben Woznicki (I worked with Ben at Hyland Software) to define common agile concepts in 5 minutes or fewer.  #NoEstimates is my second content assignment for the new project. Can you provide feedback on what I missed or where I could cut? Are there other areas that need (or deserve) this type of treatment?