Complete firstKanban
A kanban system or comparable flow process with throughput and cycle-time data from the last 6-12 weeks is available.
Without: Without flow data there is no basis for forecasts and NoEstimates turns into wishful planning.
RunsheetAgile
NoEstimates
ComplexityMedium
Timelaufend
Participants2-12
FormatWorkshop + async
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstStory splitting
The team can consistently slice work items into small chunks (rule of thumb: less than five days cycle time), and slicing techniques are known.
Without: Without small slicing, items vary too much and throughput counting is unreliable.
02
Preparation
What needs to be ready before start
Materials
Flow dashboard with throughput and cycle time (Jira, Linear, Azure DevOps, or external tools such as Actionable Agile); backlog with sliced items; forecast tool or Monte Carlo simulator; list of typical planning questions.
People / roles
A flow master or tech lead who maintains data and communicates forecasts; the delivery team; a product owner for slicing and prioritization; optional coach for methodology change.
Pre-read
Throughput data (items per week) for last 6-12 weeks; cycle-time distribution; current WIP; slicing rules; known planning questions (release date, budget, scope).
Time needed
Ongoing, setup 30-60 min, forecast 15-30 min
Setup
Export throughput data as a dataset. Configure forecast tool (Monte Carlo with 1,000+ simulations). Define a "small story" rule. Identify existing estimation rituals to replace.
03
Core question
The one question this method answers
Which planning decision do we need to make, and which flow data or slicing rules answer it more cheaply than an estimation ritual?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Define planning question | 10 min | State clearly which decision estimation should support: release date, budget, or scope cut. For each question, check whether flow data is sufficient. | Without a concrete question, NoEstimates becomes dogmatic. Some questions still require explicit estimation (for example unknown investments). Review honesty per case. |
2Phase 2: Tighten slicing | 20-30 min | Review current items for size suitability (cycle time less than 5 days). Document slicing rules, for example: "an item is small if a developer can complete it in three days." | Without small slicing, throughput mixes apples and oranges. If 30% of items are over five days cycle time, fix slicing before forecasting. |
3Phase 3: Collect throughput data | 15 min | Count completed items per week and collect at least 6-12 weeks of data. Include cycle-time distribution and mark anomalies (holidays, outages). | The data window must match the question. Use 12 weeks for quarterly forecast, 4-6 weeks for sprint forecast. Account for seasonal effects. |
4Phase 4: Generate and communicate forecast | 15-30 min | Run Monte Carlo forecast for planning question. Calculate percentiles (50%, 70%, 85%, 95%). Communicate a range: "85% chance of completion in five weeks." | Update forecasts weekly. When the system changes (new engineer, migration), discard old data windows. |
05
Artifact
What comes out at the end
Form
Flow dashboard with throughput chart and cycle-time distribution; forecast document per planning question with percentiles and assumptions; slicing rules in team wiki; list of replaced estimation rituals.
Versioning / ownership
Maintain throughput data as a time series (for example, sheet with date, completed items). Archive forecasts per planning question with date and keep old ones. Version slicing rules in the team wiki.
Tool alternatives
- Actionable Agile for Monte Carlo forecasting
- Jira with control chart and velocity report
- Linear with cycles and throughput view
- Azure DevOps with flow metrics
- Python or R scripts for custom Monte Carlo
no-estimates-working-template.md
Compact working template for NoEstimates with context, input, output artifacts, and next step.
NoEstimates Working Template
Goal
Approach that reduces explicit effort estimation and instead uses small items, throughput, and forecasting.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Throughput Data:
- Flow Forecast:
- Slicing Rules:
Assumptions and open questions
- ...
Decision / Next step
Owner, date, and success signal.
06
Example output
Concrete filled scenario, fictional example
no-estimates-beispiel.md
Concrete filled scenario, fictional example
NoEstimates - Release forecast Q3/2026, 2026-05-18
Planning question: When is release "Webhook System v1" likely to be finished? Remaining scope: 18 items.
Slicing status: 16 of 18 items are small (historical cycle time < 4 days). Two items are marked for further splitting.
Throughput: Last 12 weeks: 5, 7, 6, 4, 8, 6, 5, 7, 6, 5, 6, 7 items/week. Median 6, min 4, max 8.
Monte Carlo forecast (1,000 simulations)
- 50%: 3.0 weeks
- 70%: 3.3 weeks
- 85%: 3.6 weeks
- 95%: 4.0 weeks
Communication: "There is an 85% probability we deliver by 11.06. If the two large items are split, the 85% estimate improves to 3.4 weeks."
07
Pitfalls
Recognize symptoms and steer against them
Trap
Dogmatic anti-estimation
Symptom
Team refuses to provide any estimate even when flow data is insufficient for the planning question.
What to do
NoEstimates is a tool, not a creed. For new initiatives without flow data, use short estimation where needed. Apply it where data supports decisions and complement elsewhere.
Trap
Inconsistent slicing
Symptom
Item sizes vary widely, from one day to three weeks, so throughput counts are not meaningful.
What to do
Document and enforce slicing rules. Count items that cannot be sliced as "Spike" or "Epic" separately. Review cycle-time distribution regularly.
Trap
Forecast becomes a guarantee
Symptom
Stakeholders treat the 85% value as a committed delivery date; variation is interpreted as failure.
What to do
Always communicate likelihood, not date. Explain to stakeholders that 85% means a 15% chance of delay. Include the range in every forecast.
Trap
Outdated data
Symptom
Forecast uses six-month old data even though team size and technology have changed.
What to do
Review data windows regularly. When team structure or technology changes, discard old windows and start with fresh data. Require at least 4-6 weeks of new data before forecasting.
Trap
Slicing too fine for value flow
Symptom
Items are split so far that individual items deliver no user value, throughput appears strong while outcomes stall.
What to do
Slicing must remain vertically integrated and value-bearing. If items are only technical subtasks, value is not delivered. Add value criteria to slicing rules.
08
Stop criteria
Done signals checkable in under a minute
No throughput data from the last 6-12 weeks is available, so any forecast would be speculative.
Slicing is inconsistent and item sizes differ by factor 5+.
Team setup has changed recently, so historical data no longer matches.
Stakeholders do not accept probabilities and insist on date commitments.
The initiative is without comparison data, for example with a new tech stack and new team, so flow forecast does not hold.
The organization requires detailed estimation in budget processes; NoEstimates alone is not sufficient.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.