Agile release planning
Agile release planning is a lightweight plan that maps product goals to a series of timeboxed releases, forecasting which features can be delivered based on value and capacity. It aligns stakeholders on scope, timing, and dependencies while remaining adaptable to new information and feedback.
Key Points
- Connects product vision to near-term releases with clear goals and target windows.
- Uses prioritized epics and features with high-level estimates to forecast scope.
- Relies on team capacity and historical velocity; forecasts are not fixed commitments.
- Highlights dependencies, risks, and assumptions that affect timing and scope.
- Visually represented as a simple roadmap or release plan that is easy to update.
- Reviewed frequently and adjusted after each iteration or major feedback event.
Purpose
Provide a shared view of what value will be delivered and when, at a level suitable for stakeholder planning, budgeting, and coordination. Balance ambition and feasibility by aligning desired outcomes with capacity, risk, and uncertainty.
Typical Sections
- Release goals and success criteria.
- Scope by release (epics, features, or themes).
- Release windows, milestones, and cadence.
- Capacity and velocity assumptions.
- Dependencies, risks, and constraints.
- Assumptions and decision log.
- MVP or earliest releasable slice definition.
- Metrics and feedback plan.
- Communication and stakeholder alignment plan.
How to Create
- Clarify product vision and outcomes to define release-level goals.
- Prioritize epics and features by value, risk, and dependency.
- Estimate at a high level using story points or t-shirt sizes to gauge effort.
- Assess capacity and historical velocity to set realistic release scopes.
- Sequence features into timeboxed release windows, noting dependencies.
- Define success criteria, MVP boundaries, and key milestones.
- Document assumptions, major risks, and mitigation strategies.
- Visualize the plan in a simple roadmap or board and socialize with stakeholders.
How to Use
- Guide quarterly and PI-level planning while leaving room for change.
- Inform iteration planning and backlog refinement by showing near-term targets.
- Coordinate cross-team dependencies and external commitments.
- Track progress against release goals using burn-up charts and milestone reviews.
- Update scope or timing based on actual velocity, feedback, and risk changes.
- Communicate expectations and manage stakeholder engagement transparently.
Maintenance Cadence
- Light review after each iteration to reflect new learning and velocity.
- Deeper update every release or monthly to re-forecast and reprioritize.
- On-demand changes when major risks, dependencies, or market shifts occur.
- Quarterly alignment session with key stakeholders to confirm direction.
Example
Three-release horizon for a product:
- Release 1 (6 weeks) - Goal: Enable early value and validate core workflow. Scope: Epics E1, E2; success: 20 pilot users and NPS baseline. Assumptions: Velocity 25 points per iteration.
- Release 2 (8 weeks) - Goal: Scale usage and add compliance. Scope: Epics E3, E4; dependencies: Security review and legal sign-off. Risks: Integration latency. Metrics: Activate 200 users, error rate under 1%.
- Release 3 (8 weeks) - Goal: Optimize performance and add reporting. Scope: Epics E5, E6; contingency buffer 15% for unknowns. Decision point: Proceed to GA based on Release 2 feedback.
PMP Example Question
A product team is creating an agile release plan. Which approach best reflects good practice?
- Commit to fixed scope and dates for three releases to secure stakeholder approval.
- Forecast features per release based on velocity and priorities, and adjust after each iteration.
- Delay release planning until detailed user stories are fully estimated.
- Set a single long release with no milestones to reduce coordination overhead.
Correct Answer: B — Forecast features per release based on velocity and priorities, and adjust after each iteration.
Explanation: Agile release planning provides a capacity-based forecast tied to value and is refined frequently with new data. It avoids rigid commitments and embraces iterative replanning.
HKSM