HKSM

A Release Planning Schedule is a high-level forecast that maps prioritized Product Backlog items to target release windows or dates. It is created during Release Planning using empirical velocity, sprint cadence, and dependencies, and is refined after each sprint to keep stakeholder expectations realistic.

Key Points

• Output of Conduct Release Planning; input to Sprint Planning and ongoing backlog refinement.
• Forecasts which user stories or MMFs will likely ship in each release window, not a detailed task plan.
• Built on empirical team velocity, sprint length, capacity, and dependencies.
• Continuously updated after Sprint Reviews and Retrospectives to reflect new information.
• Aligns business goals with delivery cadence and communicates release goals to stakeholders.
• Links to Definition of Done and release criteria to ensure readiness and quality.

Purpose

The schedule gives a transparent, shared view of when valuable increments may be delivered. It helps the Product Owner balance scope, time, and value across releases.

It also provides a planning baseline for budgeting, marketing, training, and operational readiness while keeping flexibility to adapt as velocity and priorities change.

Key Terms & Clauses

• Release goal: The outcome or value theme the release aims to achieve.
• Release window/date: Target timeframe for deployment, preferably a range when uncertainty is high.
• Sprint cadence: Fixed sprint length and number of sprints planned per release.
• Velocity and capacity: Historical or forecast points per sprint adjusted for team availability.
• MMFs/User stories: Minimum marketable features or grouped stories mapped to releases.
• Dependencies and assumptions: Technical, vendor, or cross-team links that can affect timing.
• Release criteria: Definition of Done, quality gates, compliance, and readiness checks.
• Buffer/contingency: Reserved capacity for risk, rework, and integration.

How to Develop/Evaluate

1. Gather inputs: Product Vision, Prioritized Product Backlog, Definition of Done, historical velocity, team availability, and known dependencies.
2. Select cadence: Confirm sprint length and initial number of sprints per release; note planned breaks or holidays.
3. Forecast capacity: Use empirical velocity or a conservative range if the team is new; apply capacity adjustments.
4. Map scope to releases: Sequence MMFs/stories by value and dependency order; allocate to sprints until capacity is reached.
5. Set release windows: Assign target dates or ranges and include assumptions, risks, and buffer.
6. Validate with stakeholders: Review trade-offs, constraints, and release criteria; refine until feasible and valuable.
7. Evaluate continuously: After each sprint, compare actuals to plan (e.g., release burn-up) and update the schedule.

How to Use

• In Sprint Planning, to ensure sprint goals align with the next release goal and capacity.
• During Product Backlog refinement, to prioritize items likely to enter the upcoming release.
• In Sprint Review, to compare forecast vs actual velocity and adjust future release windows.
• For stakeholder communication, budgeting, and go-to-market coordination across teams.
• As input to risk management by highlighting dependencies and needed integration work.

Example Snippet

Lightweight, rolling forecast:

• Release 1 (Sprints 1-3; target window: Mar 10-24): Goal - Onboard new users. Scope - MMF-A (US-12, US-18), MMF-B (US-7). Assumptions - Velocity 28-32 pts/sprint.
• Release 2 (Sprints 4-6; target window: May 5-19): Goal - Self-service improvements. Scope - MMF-C (US-21, US-22, US-30). Risks - API dependency; 15% buffer applied.
• Release 3 (Sprints 7-8; target window: Jun 20-30): Goal - Performance hardening. Scope - Tech debt and NFR stories; release only if criteria met.

Risks & Tips

• Risk: Overcommitting based on wishful velocity. Tip: Use empirical data and ranges.
• Risk: Ignoring dependencies and lead times. Tip: Visualize cross-team and vendor links.
• Risk: Treating dates as fixed contracts. Tip: Negotiate scope-date trade-offs openly.
• Risk: No buffer for integration or defects. Tip: Reserve capacity each sprint and per release.
• Risk: Stale schedule after scope or velocity shifts. Tip: Update after every Sprint Review.
• Risk: Quality shortcuts to hit dates. Tip: Enforce Definition of Done and release criteria.

PMP/SCRUM Example Question

The team’s average velocity dropped after onboarding new members. The Product Owner wants to maintain the original release date without changing scope. What should the Scrum Master advise?

1. Extend sprint length to increase the velocity and keep the date.
2. Ask the team to work overtime until the original release plan is met.
3. Update the Release Planning Schedule and collaborate to adjust scope or date.
4. Freeze the Product Backlog to prevent any further changes.

Correct Answer: C — Update the Release Planning Schedule and collaborate to adjust scope or date.

Explanation: Velocity changes require updating the forecast. The schedule is a living artifact; the right response is to replan and negotiate scope-date trade-offs, not to change sprint length or push overtime.