HKSM

A living plan that shows the latest forecast of release windows, target dates, and scope across upcoming sprints. It is first created during Conduct Release Planning and then revised based on new velocity data, backlog changes, risks, and stakeholder feedback to guide delivery and communication.

Key Points

• Time-phased view of planned releases, target dates, and forecasted content.
• Initially produced in Conduct Release Planning and updated after Sprint Review and Retrospect.
• Owned by the Product Owner with input from the Scrum Team and stakeholders.
• Driven by empirical data such as velocity trends, refined backlog, and risk status.
• Acts as an input to Sprint Planning, dependency coordination, and stakeholder communication.
• Remains flexible; changes are transparent and traceable to backlog and capacity shifts.

Purpose

The goal is to provide a current, realistic forecast of when meaningful increments will be released and what they include. It aligns expectations, supports trade-off decisions between scope, date, and quality, and coordinates teams and external dependencies.

By updating it frequently, the team reduces uncertainty, avoids surprises, and keeps delivery plans synchronized with real progress and changing priorities.

Key Terms & Clauses

• Release: A packaged set of Done user stories delivered to users or a production environment.
• Release window: The time frame or target date for deploying a release.
• Release goal: The outcome or theme the release aims to achieve, linked to business value.
• Velocity: The empirically measured throughput per sprint used for forecasting.
• Forecast range: Date and scope expressed with ranges to reflect uncertainty.
• Dependencies: Internal or external items that can impact release timing or content.
• Assumptions and constraints: Noted conditions that shape the plan, such as fixed dates or regulatory milestones.
• Buffers: Explicit schedule or scope margins reserved for risk and variability.

How to Develop/Evaluate

To update the schedule, gather current inputs from recent Sprint Review and Retrospect outcomes, the refined Prioritized Product Backlog, velocity data, risks, and dependency status.

• Recalculate capacity using the latest velocity trend and known availability.
• Map prioritized user stories to upcoming sprints and releases based on value and dependencies.
• Run scenarios: fix-date with variable scope, or fix-scope with date range, highlighting trade-offs.
• Add buffers for high-uncertainty epics, integration, and external approvals.
• Validate with the Scrum Team; adjust for Definition of Done, quality gates, and integration needs.
• Review with key stakeholders; document decisions, assumptions, and changes to release goals.

How to Use

The Product Owner uses the updated schedule to communicate likely release timing and content, and to drive prioritization decisions. The Scrum Team uses it during Sprint Planning and Commit User Stories to focus on items that advance the next release goal.

In SBOK flow, it is created in Conduct Release Planning, updated after Demonstrate and Validate Sprint and Retrospect Sprint, and referenced during Refine Prioritized Product Backlog and in Scrum of Scrums for cross-team coordination. It also informs Ship Deliverables activities and stakeholder readiness plans.

Example Snippet

Below is a simple, text-based example of an updated schedule:

• Release R1 — Target: Feb 10-17 — Sprints 1-3 — Goal: Core onboarding — Scope: 28-32 points — Assumptions: No external API changes.
• Release R2 — Target: Mar 20-27 — Sprints 4-6 — Goal: Reporting MVP — Scope: 30-36 points — Dependency: Data team integration by Mar 5.
• Release R3 — Target: Apr 24-May 1 — Sprints 7-8 — Goal: Performance hardening — Scope: 18-22 points — Buffer: 15 percent for optimization work.

Risks & Tips

• Avoid false precision; communicate ranges and assumptions to reflect uncertainty.
• Do not treat the schedule as a contract; keep it flexible and empirical.
• Update promptly after notable velocity shifts, scope changes, or new risks.
• Expose dependencies early; include lead times for approvals, security, and operations.
• Align release goals to business value to ease scope trade-offs when dates are tight.
• Keep buffers visible; do not silently consume them without stakeholder awareness.

PMP/SCRUM Example Question

A team completes two sprints with lower-than-expected velocity, and a new high-priority epic is added. What should the Product Owner do next?

1. Extend the sprint length to recover lost time.
2. Lock the scope to protect the original release dates.
3. Reassign developers mid-sprint to speed up delivery.
4. Update the Release Planning Schedule and communicate revised forecasts.

Correct Answer: D — Update the Release Planning Schedule and communicate revised forecasts.

Explanation: The updated schedule reflects new velocity and backlog changes, enabling transparent trade-offs and expectation management. Changing sprint length, locking scope, or reassigning mid-sprint conflicts with Scrum principles and may create more risk.