Overview
Based on "Agile Estimating and Planning" by Mike Cohn. The core insight: release dates are not commitments - they are probabilistic forecasts. Velocity is a lagging indicator that gets more reliable over time (the cone of uncertainty narrows). A good release plan gives a date range, not a single date, and explicitly buffers for unknowns. Single-date commitments made from a backlog on day one are fiction.
Workflow
Step 1: Establish velocity baseline
Ask the user for sprint velocity data. You need at least 3 sprints of history for a meaningful average.
Sprint | Story Points Completed
-------|----------------------
S-1 | [number]
S-2 | [number]
S-3 | [number]
Calculate:
- Average velocity: sum / number of sprints
- Velocity range: min to max (this defines your planning range)
If no historical data exists, flag this: "No velocity history means your first release plan has a high cone of uncertainty. Revisit after 2-3 sprints."
Step 2: Size the remaining backlog
Ask for the current backlog in story points. If the backlog is not estimated, do not attempt to generate a plan - ask the user to size the top items first.
Group the backlog:
- Must have (P0): work required for the release to ship
- Should have (P1): high-value, included if time permits
- Nice to have (P2): deferred if velocity is lower than expected
Step 3: Calculate the release forecast
Using the velocity range from Step 1:
Optimistic date: P0 points / max velocity = [N] sprints
Realistic date: P0 points / avg velocity = [N] sprints
Conservative date: (P0 + P1 points) / min velocity = [N] sprints
Convert sprints to calendar dates using sprint length (ask user: 1-week, 2-week, or 3-week sprints?).
Output format:
RELEASE FORECAST - [your program]
==================================
Optimistic: Ship by [date] (P0 scope only, best-case velocity)
Realistic: Ship by [date] (P0 scope, average velocity)
Conservative: Ship by [date] (P0+P1 scope, worst-case velocity)
Recommended commitment: [realistic date] with [conservative date] as contingency
Step 4: Apply risk buffers
Cohn's rule: buffer 20% for unknowns if the team is mature and the codebase is known. Buffer up to 50% for:
- New team (< 3 sprints together)
- Greenfield build with no precedent
- External dependencies not yet confirmed
- Compliance, security, or legal review required
Add the buffer to the realistic estimate:
Buffered release date = realistic date + (realistic duration × buffer %)
Explicitly state what the buffer covers:
- "[X]% buffer for [integration risk with third-party API / new team ramp-up / unknown legacy behavior]"
Step 5: Identify sprint-by-sprint milestones
Break the release into checkpoints. Use Cohn's planning horizon principle: plan in detail for the next 1-2 sprints, rough milestones for the rest.
SPRINT MILESTONES
Sprint 1-2: [specific deliverables - detailed]
Sprint 3-4: [milestone checkpoint - e.g., "core feature complete, integration testing starts"]
Sprint 5: [scope decision point - P1 items in or out based on velocity trend]
Sprint 6: [release candidate, regression, final go/no-go]
Step 6: Define the go/no-go criteria
State explicitly what must be true on the release date for the team to ship:
- P0 stories: all accepted
- Critical defects: zero Sev 1, fewer than [N] Sev 2
- Performance: [metric] meets [threshold]
- External dependencies: [list] confirmed resolved
Anti-Patterns
1. Committing to a single date from day one
Bad: "We will ship on March 15th" based on a rough backlog estimate.
Good: "Our realistic forecast is March 15th ± 2 sprints. We will tighten this after Sprint 3."
2. Planning without velocity data
Bad: Generating a release date when the team has never shipped together.
Good: Flag the uncertainty, provide a range 2x wider than normal, revisit after 3 sprints.
3. Forgetting to account for interrupt work
Bad: Planning every story point of velocity for feature work.
Good: Reserve 15-20% of velocity for bugs, support escalations, and unplanned work - especially for teams with external customers.
4. No scope buffer - only time buffer
Bad: Fixed scope + fixed date with only a time buffer.
Good: Designate P1 items as scope buffer. If velocity is low, cut P1 - don't extend the date.
5. Milestones too far apart
Bad: "Done by Q3" with no intermediate checkpoints.
Good: A milestone every 2-3 sprints so you detect drift early, not at the end.
Quality Checklist