Release Planning with Planning Poker
Estimating a sprint is one thing. Estimating an entire release with 50+ items is another. But with the right techniques, Planning Poker scales to release planning too.
The Release Planning Challenge
- Many items: 50-200 stories to estimate
- Less detail: release-level items often aren’t refined yet
- Long horizon: 2-6 months of uncertainty
- Impatient stakeholders: they want a date
Layered Estimation Strategy
Level 1: Epics (T-Shirt Sizing)
Estimate large work blocks with T-shirt sizes:
- Epic “Checkout”: XL
- Epic “Catalog”: L
- Epic “Notifications”: M
This gives you a high-level view in 30-60 minutes.
Level 2: Features (Planning Poker with an Expanded Scale)
For each epic, estimate features using larger values:
| Feature | Points |
|---|---|
| Credit card checkout | 13 |
| PIX checkout | 8 |
| Discount coupon | 5 |
| Checkout Subtotal | 26 |
Level 3: Stories (Normal Planning Poker)
For features scheduled in the next sprint, estimate normally using Fibonacci (0.5-13).
Calculating the Release
The Formula
Total release points = sum of all estimated items
Number of sprints = total points / team's average velocity
Estimated date = current sprint + calculated number of sprintsPractical Example
| Epic | Points |
|---|---|
| Checkout | 26 |
| Catalog | 18 |
| Notifications | 13 |
| Reports | 8 |
| Performance | 5 |
| Total | 70 |
Average velocity: 25 points/sprint Sprints needed: 70/25 = ~3 sprints With 2-week sprints: ~6 weeks
Adding Uncertainty Buffer
For longer releases, add a buffer:
- 1-2 month release: +15% buffer
- 3-4 month release: +25% buffer
- 5+ month release: +40% buffer
In the example above (3 sprints): 70 + 25% = ~88 points → ~3.5 sprints → 7 weeks.
Handling Uncertainty in Items
Classify by Confidence
- High confidence: items already refined → accurate estimate
- Medium confidence: items with description but no detail → estimate ±30%
- Low confidence: vague epics → estimate ±50%
Use Date Ranges
Bad: “The release will be ready on August 12.” Good: “The release will be ready between August 5 and 19, most likely the second week.”
Revise Every Sprint
Each sprint, recalculate:
- Points delivered vs. planned
- Updated velocity
- Revised estimated date
Stakeholders should see this update weekly.
Multi-Team Release Planning
When multiple squads contribute to a release:
- Estimate per team — each squad estimates their scope
- Map dependencies — who depends on whom
- Sum the velocities — combined team velocity
- Identify the critical path — the slowest dependency dictates the timeline
Example
| Squad | Points | Velocity | Sprints |
|---|---|---|---|
| Squad A (Checkout) | 30 | 25/sprint | 1.2 |
| Squad B (Backend) | 20 | 20/sprint | 1.0 |
| Squad C (Mobile) | 15 | 15/sprint | 1.0 |
But if Squad C depends on Squad B, and Squad B depends on Squad A:
- Sprint 1: Squad A
- Sprint 2: Squad B
- Sprint 3: Squad C
- Total: 3 sprints (not 1.2)
Dependencies matter!
Tools for Release Planning
- Jira Advanced Roadmaps: visual timeline with dependencies
- Dev in Poker: fast estimation of many items
- Miro/FigJam: visual mapping of epics and dependencies
- Spreadsheets: practical for simple calculations
Conclusion
Release Planning with Planning Poker is feasible and efficient when done in layers: T-Shirt sizing for epics, Planning Poker for features, and progressive detail as the release approaches. Communicate ranges, not fixed dates, and revise every sprint.