HKSM

Collaborative workshops where the Product Owner, Scrum Master, Scrum Team, and key stakeholders forecast one or more releases by mapping prioritized backlog items to a timeline based on capacity, risks, and dependencies. The session produces a Release Plan with goals, target dates, and a sprint-level delivery forecast.

Key Points

• Facilitated workshop to plan upcoming releases at a high level.
• Uses team velocity and capacity to create a realistic delivery forecast.
• Aligns release goals with business value, risks, and constraints.
• Produces a Release Plan that maps user stories or features to sprints and target dates.
• Treats the plan as a living forecast, updated after each sprint review.
• Enables stakeholder alignment on scope, dates, and quality expectations.

Purpose of Analysis

Release Planning Sessions analyze the relationship between desired scope, available capacity, and schedule constraints to build a feasible release roadmap. They help translate business goals into incremental deliveries that can be inspected and adapted as empirical data emerges.

The session surfaces risk hotspots, cross-team dependencies, and quality considerations so they can be managed early. It frames trade-offs among scope, time, and resources while protecting the Definition of Done.

Method Steps

1. Set context and goals: confirm business outcomes, release windows, and major constraints.
2. Review prioritized backlog: walk through epics and top user stories with acceptance criteria.
3. Establish or validate capacity: use historical velocity and known availability for the release horizon.
4. Sequence and slice: order work for value and risk, and split large items to fit within sprint capacity.
5. Map to sprints: tentatively allocate items to sprints based on capacity, dependencies, and risk.
6. Identify risks and dependencies: record mitigation actions and owners; adjust the plan if needed.
7. Define release goals and quality expectations: confirm Definition of Done and any release-specific readiness criteria.
8. Create the Release Plan: document target dates, sprint markers, scope forecast, and assumptions.
9. Communicate and agree on next checks: set review points and how changes will be handled.

Inputs Needed

• Prioritized Product Backlog with epics and user stories.
• Business objectives, market windows, and compliance deadlines.
• Historical team velocity and upcoming capacity/availability.
• Definition of Done and quality policies.
• Known risks, assumptions, and dependency information.
• Architecture or integration constraints and release readiness criteria.

Outputs Produced

• Release Plan (Release Planning Schedule) with goals, target dates, and sprint-level forecasts.
• Backlog mapped to releases and sprints, with high-level acceptance criteria highlighted.
• Updated risks, assumptions, and dependencies with mitigation actions and owners.
• Baseline for a release burndown or burnup view to track progress over time.
• Communication approach for stakeholders regarding scope changes and forecast updates.

Interpretation Tips

• Treat the Release Plan as a forecast, not a fixed contract; update it after each sprint.
• Use empirical velocity from completed sprints to refine future sprint allocations.
• Watch for dependencies grouped in the same sprint that exceed capacity; spread them appropriately.
• Track risks that threaten release goals and keep contingency visible in the plan.
• If capacity changes, adjust scope first before considering date changes or quality trade-offs.

Example

A team has a historical velocity of 30 points per two-week sprint. The top of the backlog shows 180 points desired for the next quarter. With six sprints in the quarter, the forecast capacity is about 180 points, assuming stable conditions.

The team slices two large stories, sequences high-value items earlier, and maps about 25-28 points per sprint to allow for risk and support work. They define a release goal for the end of sprint 3 and a second release at the end of sprint 6, documenting risks and dependencies for integration.

Pitfalls

• Treating the release forecast as a hard commitment instead of a plan subject to change.
• Ignoring capacity constraints, holidays, or parallel initiatives.
• Skipping stakeholder involvement, leading to misaligned goals and surprise trade-offs.
• Overstuffing early sprints without reserving capacity for integration and defects.
• Failing to slice large items, causing rollover and unreliable forecasts.
• Letting the plan go stale by not updating it after each sprint review.

PMP/SCRUM Example Question

During a release planning session, the Product Owner wants 240 points of scope delivered in 12 weeks. The team’s historical velocity is 30 points per two-week sprint. What should the Scrum Master recommend?

1. Commit to all 240 points and plan overtime to meet the deadline.
2. Forecast four sprints (about 120 points) and facilitate scope trade-offs or phased releases.
3. Add more developers immediately and keep the original scope and date.
4. Re-estimate all stories lower so that they fit within four sprints.

Correct Answer: B — Forecast four sprints (about 120 points) and facilitate scope trade-offs or phased releases.

Explanation: Empirical velocity suggests about 120 points in four sprints. The Scrum Master should promote a realistic forecast and enable negotiation on scope or release phasing, not inflate capacity or manipulate estimates.