The NoEstimates movement started as a provocation and evolved into a legitimate forecasting methodology. Its central observation: teams spend significant effort estimating story points, yet simply counting items completed often produces comparable forecasting accuracy.
This isn't about abandoning all prediction. It's about shifting from effort-based estimates to flow-based measurements. Instead of asking "how big is this?" we ask "how fast do things move through our system?"
The Case Against Traditional Estimation
Story point estimation has well-documented problems:
Estimation Consumes Time: Planning poker sessions, refinement meetings, and re-estimation when scope changes consume hours that could be spent building. For a typical team, estimation overhead reaches 5-10% of total capacity.
Points Don't Transfer: A team's story points are internal currency. You can't compare Team A's "8" with Team B's "5." Yet organizations routinely try, creating false equivalencies.
Accuracy Is Questionable: Research on estimation accuracy is sobering. Teams routinely underestimate by 50-100%. The more complex the work, the worse the estimates.
Anchoring Effects: Once a number is spoken, it anchors discussion. First estimates disproportionately influence final consensus regardless of accuracy.
Gaming Incentives: When velocity becomes a performance metric, teams inflate estimates to show "improvement." Points inflate while actual output remains constant.
Throughput: The Core Metric
Throughput measures items completed per time period—stories per sprint, features per month, bugs fixed per week. No estimation required; simply count what's done.
Throughput-based forecasting works because of a statistical observation: when work items are reasonably similar in size, their completion rate provides sufficient forecasting accuracy without explicit estimation.
The key enabling practice: right-sized stories. If stories are small enough to complete within a sprint and roughly comparable in scope, counting items works as well as weighted point systems.
Implementing Throughput Forecasting
Step 1: Enforce Story Slicing
Throughput forecasting requires consistent story sizes. Invest the time saved from estimation into story slicing:
- No story spans multiple sprints
- Stories complete within 2-3 days ideally
- Use splitting patterns to break down large items
- Track items that take unexpectedly long; analyze why
This isn't about making stories artificially small. It's about finding natural boundaries that create independently valuable increments.
Step 2: Measure Historical Throughput
Track items completed per sprint for the past 10+ sprints. Calculate:
- Average throughput
- Standard deviation
- Minimum and maximum values
- Trend direction (improving, stable, declining)
This historical distribution becomes your forecasting input.
Step 3: Apply Monte Carlo
With throughput history, Monte Carlo simulation predicts completion dates:
- Randomly sample from historical throughput for simulated sprint 1
- Subtract completed items from remaining scope
- Repeat for subsequent sprints until scope exhausted
- Record how many sprints the simulation required
- Run 10,000+ simulations
- Report percentile outcomes (85% confidence, 95% confidence)
Step 4: Present Probabilistic Forecasts
Communicate results as probability ranges:
- "Given 47 remaining items and our historical throughput, we'll complete them in 4-6 sprints with 85% confidence"
- "There's 50% probability we finish by Sprint 24, 85% by Sprint 26, 95% by Sprint 28"
When NoEstimates Works Best
Throughput forecasting excels in specific contexts:
Mature Teams: Teams with stable membership and established processes show consistent throughput. New teams have volatile throughput that undermines forecasting.
Similar Work Items: Backlogs with uniformly-sized stories benefit most. Highly variable item sizes reintroduce the estimation problem.
Continuous Flow: Kanban teams with steady work flow generate clean throughput data. Start-stop project teams show noisier patterns.
Forecasting Horizons: Long-range forecasts (next quarter) benefit more than short-range (next sprint). The Law of Large Numbers smooths variation over time.
When Estimation Still Helps
NoEstimates isn't universally applicable. Estimation remains valuable for:
Highly Variable Work: When items genuinely vary 10x in size (a configuration change vs. a new subsystem), ignoring size loses information.
Capacity Planning: If you need to know whether a team can absorb additional work, understanding relative sizes helps.
Prioritization Discussions: Size estimates inform value/effort tradeoffs during backlog prioritization.
Team Calibration: Planning poker's real value is conversation, not numbers. Discussion reveals assumptions, dependencies, and risks that throughput metrics can't surface.
Tools like FreeScrumPoker support lightweight estimation for these scenarios without requiring full velocity tracking infrastructure.
Hybrid Approaches
Many teams adopt hybrid models:
T-Shirt Sizing + Throughput: Quick S/M/L classification during refinement ensures stories are appropriately sized, then throughput forecasting handles prediction.
Estimate Only Large Items: Items expected to take more than a few days get quick estimates; smaller items go unestimated into throughput calculations.
Right-Sizing Enforcement: Use estimation only to identify items that need further splitting—any item above a threshold triggers decomposition discussion.
Organizational Resistance
Dropping story points often triggers organizational pushback:
"How will we compare teams?" The answer: you shouldn't. Team comparison using velocity creates gaming incentives and ignores context differences.
"How will we track improvement?" Track cycle time reduction, quality metrics, customer satisfaction—outcomes that matter, not activity proxies.
"How will we make commitments?" Probabilistic forecasts provide more honest commitments than point-based projections that ignore uncertainty.
Leadership education is essential. NoEstimates requires organizational trust that teams are delivering value without activity-based performance metrics.
Measuring Success
Teams transitioning to throughput forecasting should track:
- Time Saved: Hours recovered from reduced estimation meetings
- Forecast Accuracy: How often did probabilistic forecasts prove correct?
- Story Size Consistency: Are items completing in similar timeframes?
- Lead Time Trends: Is work flowing faster as the system optimizes?
Conclusion
NoEstimates isn't about flying blind. It's about recognizing that detailed estimation often provides false precision while consuming real time. Throughput-based forecasting substitutes measurement for speculation, using actual performance data to predict future outcomes.
The approach works when teams invest in story slicing, maintain consistent work patterns, and communicate probabilistic rather than deterministic forecasts. For teams drowning in estimation meetings with little forecasting accuracy to show for it, throughput-based approaches offer a compelling alternative.
Start with a pilot: run throughput forecasting in parallel with existing estimation for a few sprints. Compare accuracy. If throughput proves comparable or better, the hours recovered from estimation meetings become available for actual product development.