NoEstimates panders to mismanagement and developer insecurity
Why do so few software development teams regularly attempt to estimate the duration of the feature/task/functionality they are going to implement?
Developers hate giving estimates; estimating is very hard and estimates are often inaccurate (at a minimum making the estimator feel uncomfortable and worse when management treats an estimate as a quotation). The future is uncertain and estimating provides guidance.
Managers tell me that the fear of losing good developers dissuades them from requiring teams to make estimates. Developers have told them that they would leave a company that required them to regularly make estimates.
For most of the last 70 years, demand for software developers has outstripped supply. Consequently, management has to pay a lot more attention to the views of software developers than the views of those employed in most other roles (at least if they want to keep the good developers, i.e., those who will have no problem finding another job).
It is not difficult for developers to get a general idea of how their salary, working conditions and practices compares with other developers in their field/geographic region. They know that estimating is not a common practice, and unless the economy is in recession, finding a new job that does not require estimation could be straight forward.
Management’s demands for estimates has led to the creation of various methods for calculating proxy estimate values, none of which using time as the unit of measure, e.g., Function points and Story points. These methods break the requirements down into smaller units, and subcomponents from these units are used to calculate a value, e.g., the Function point calculation includes items such as number of user inputs and outputs, and number of files.
How accurate are these proxy values, compared to time estimates?
As always, software engineering data is sparse. One analysis of 149 projects found that 
, with the variance being similar to that found when time was estimated. An analysis of Function point calculation data found a high degree of consistency in the calculations made by different people (various Function point organizations have certification schemes that require some degree of proficiency to pass).
Managers don’t seem to be interested in comparing estimated Story points against estimated time, preferring instead to track the rate at which Story points are implemented, e.g., velocity, or burndown. There are tiny amounts of data comparing Story points with time and Function points.
The available evidence suggests a relationship connecting Function points to actual time, and that Function points have similar error bounds to time estimates; the lack of data means that Story points are currently just a source of technobabble and number porn for management power-points (send me Story point data to help change this situation).
This is the first that I’ve heard of developers leaving or avoiding positions just because management was asking for estimates.
It’s the unknown unknowns that get us. Despite being one of the few developers I know who does explicit design work before starting to implement something, my estimating ability is not something I brag about. My own data of my estimating ability (for new features, n=91; collected from 2007-2020) shows a (final time / estimated time) ratio with mean = 1.73, meaning I can easily underestimate by half.
I concur with Grant. At our company, documented high-level design and GANTT charts were required. Our biggest headache was managers trying to whittle down estimates. (As you can guess, the result was never accurate.)
@Grant Schultz
I think that there are business domains where estimating is the norm, and the software people have to fall in line. Based on my limited experience, this seems to be domains where software is a component of a larger product.
While I am happy to talk to any software group, for most of the people I talk to, software is the primary product (and the companies tend to be relatively young). Young, pure play software companies tend to be the wild west (although I know of one that did estimate and gave me their data).
* When anybody asks me to measure something, I _immediately_ say, it’s 42…. what are you going to do about it? Mostly they go grrumble grrumble and go away.
* Proper estimation is a data and time intensive exercise in probabilistic modeling… If that is what you want to invest my time in… fine. But you will be trading value producing time and effort for estimates with wide uncertainty, your choice.
* Software Development is fundamentally “basic research”, _everything_ we do has _never_ been done before. If it has been done before, it’s system admin… aka installing and configuring a preexisting package.
* Thumb suck estimation is so inaccurate… does it really have any value?
@John Carter
How does your company plan for product launch?
@John Carter
Estimating requires practice like anything else. If you never bother to estimate or subsequently measure actual time, then of course it’s going to feel overly difficult. Knowing how much software costs matters a lot for real business ventures.