#NoEstimates: Should We Still Be Estimating?
The #NoEstimates movement emerged as a response to the frustration of inaccurate estimates and the time spent in planning sessions. The core idea: instead of estimating, deliver frequently and use real data to plan.
The NoEstimates argument
Estimates are waste
“If we ship a feature a day, why spend 2 hours estimating 10 of them?”
Response: Estimates aren’t about knowing the individual cost of each feature. They’re about informing priority. A 13-point feature might rank lower than a 3-point one if their business value is similar.
Real data beats estimates
“Historical lead time shows we deliver 5 features/week. Use that, not story points.”
Response: Partially true. Lead time is fantastic for predicting throughput. But it doesn’t answer: “Does this big feature fit in the next sprint?”
Estimates create false precision
“Saying 5 points creates the illusion that we know what’s going to happen.”
Response: Estimates are forecasts with confidence intervals, not guarantees. The problem isn’t estimation — it’s treating an estimate as a promise.
When NoEstimates works
A mature team with stable flow
Teams that consistently deliver ~5 features per sprint can simply use throughput as their planning metric.
Products with similarly-sized features
If almost every feature takes 2-3 days, estimating each one individually adds little value.
Kanban teams
Kanban doesn’t require estimates by default. Lead time and throughput serve perfectly well as planning metrics.
When estimates are essential
Features with wildly different sizes
If one feature takes 2 days and another takes 3 weeks, flying blind on planning is a recipe for disaster.
Stakeholders need predictability
Executives need to know whether a launch will make Q3. “We deliver 5 features per sprint” doesn’t tell them whether the 20 items in the backlog fit into 12 weeks.
Investment decisions
Choosing between building X or Y requires understanding the relative effort of each option.
New teams
Without historical data, estimates are the only guide a team has.
Our take: Right-Sized Estimation
The answer isn’t “always estimate everything” or “never estimate at all.” It’s estimate when the value of the information outweighs the cost of the estimate.
Estimate when:
- Tasks vary significantly in size
- Priority decisions depend on effort
- Stakeholders need release forecasts
- The team is still calibrating its velocity
Skip the estimate when:
- Tasks are consistently similar in size
- You already have enough throughput data
- The cost of estimating exceeds the value of the information
- It’s an obvious, recurring task
A practical middle ground
Many teams adopt a lightweight approach:
- Planning Poker for larger features (> 5 points)
- Default size (e.g., 3 points) for small, similar features
- Throughput for bugs and maintenance tasks
Conclusion
The NoEstimates debate raised valid points: overly granular or excessive estimation is indeed wasteful. But the solution isn’t to abolish estimation entirely — it’s to estimate intelligently, at the right moments, with the right level of detail.