In the spirit of the Agile manifesto, which guides us to be “uncovering better ways of developing software by doing it and helping others do it,” many in the agile community are finding alternatives to traditional Estimation. Indeed, none other than manifesto signer Ron Jeffries has advocated for such approaches, saying:

Estimation is very difficult, perhaps impossible, and often misused.
Estimates are always waste; they are not our product. We wish to reduce this waste, as with all waste. Therefore we should always wish to reduce estimates.
When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before.

One approach (or perhaps banner for a way of thinking) is NoEstimates. This itself can range in terms of meanings, but can include:

Probabilistic Forecasting as a way to answer the question “When will it be done?”
A value- or outcomes-oriented approach to delivery
Risk-mitigation in project management

NoEstimates Tips

If you’re that worried about how long things will take and have no idea how much value you expect to gain, you probably shouldn’t be doing software in the first place. (Vasco’s rule of 10x)
Know what variables actually matter to success. The single most important unknown is whether the project will be canceled. The next most important variable is utilization of the system, including how quickly the system rolls out and whether some people will use it at all. (Douglas Hubbard)
Understand why you’re estimating and whether your estimates actually have any predictive information value.
Duration (aka delivery or cycle time) of knowledge work isn’t normally distributed, so don’t use averages. (Or control charts)
If someone asks you for an estimate, always give it in a range (not a single number). The future is probabilistic!
Effort is but one of many sources of variation (accounting for maybe 15% of total delivery time), so don’t use it, unless you want to be at least 85% off. (Troy Magennis)
Delivery time includes all sources of variation, so use it to create a probabilistic forecast.
Work in Progress and Collaboration Policy are the two most-important variables for predictability and delivery time, so work to improve those instead of trying to get better at estimating. (Dimitar Bakardzhiev)