Scrum Master Exam: Forecasting and Release Planning (2026 Guide)

If there's one area where Scrum exam candidates consistently lose points, it's forecasting and release planning. Not because the concepts are complicated, but because most of us come into Scrum with years of Gantt chart conditioning. We instinctively reach for fixed dates and detailed long-term schedules — and then wonder why the exam keeps marking those answers wrong.

The truth is, Scrum doesn't abandon planning. It transforms it. Instead of locking in a roadmap on day one and hoping reality cooperates, Scrum uses empirical data — what the team has actually done — to make honest, adaptive forecasts. That's a fundamentally different philosophy, and the PSM I and CSM exams test whether you've genuinely internalized it.

This guide walks you through everything you need for the forecasting and release planning section of your exam: the "why" behind empiricism, the tools Scrum uses to track progress, how the Product Owner navigates stakeholder pressure, and the critical distinction between a forecast and a commitment. Work through this carefully and you'll not only answer exam questions correctly — you'll understand Scrum deeply enough to apply it on day one.

---

Introduction to Forecasting in a Scrum Environment

Forecasting in Scrum starts with a simple but powerful idea: you can't know everything upfront, so stop pretending you can. The Scrum Guide 2020 describes Scrum as founded on empiricism and lean thinking, where knowledge comes from experience and decisions are based on observable facts rather than theoretical projections.

In practice, this means a Scrum Team doesn't promise to deliver a fixed scope by a fixed date. Instead, they inspect their actual progress — how much work they're completing each Sprint, what obstacles are slowing them down, how requirements are evolving — and use that data to make rolling forecasts. Those forecasts get more accurate over time as the team builds a track record.

Think of it like navigation before GPS. A ship's captain using dead reckoning didn't know exactly where the currents would push them, but they used known speed, heading, and elapsed time to make their best estimate — and they updated that estimate constantly as new information arrived. Scrum forecasting works the same way. You're not guessing blindly, and you're not locked into a fixed course. You're making informed estimates that improve sprint by sprint.

What the Scrum Guide Says About Forecasting

The 2020 Scrum Guide specifically uses the word "forecast" when describing the Sprint Backlog — it's described as a plan by and for the Developers, consisting of the Sprint Goal, the Product Backlog items selected for the Sprint, and a forecast for delivering the Increment. This word choice is intentional. It signals that what the team is doing is their best current projection, not a contractual guarantee.

---

Why Scrum Replaced Traditional Project Planning

Traditional project management — the kind built around detailed upfront plans, fixed scope, and Gantt charts — works reasonably well when requirements are stable and the work is highly predictable. Building a bridge follows physics. Writing new software, developing a product nobody has built before, or responding to a rapidly changing market? That's a different beast entirely.

The problem with traditional plans in complex environments isn't that people are bad at planning. It's that detailed long-term plans create a false sense of certainty. Teams commit to schedules based on assumptions that will be wrong. When reality diverges from the plan — and it always does — the instinct is often to protect the plan rather than adapt. Scope gets cut quietly. Quality suffers. Teams work overtime to hit a date that was never realistic.

Scrum's founders, Ken Schwaber and Jeff Sutherland, codified what experienced practitioners already knew: in complex product development, you can't eliminate uncertainty, but you can build a framework that works with uncertainty instead of against it. The three pillars of empiricism — transparency, inspection, and adaptation — replace the illusion of predictability with genuine responsiveness.

The Cost of Rigidity in Product Development

Here's a scenario that will resonate if you've worked in software: a team spends three months building features according to a plan locked in during a two-day requirements workshop. Six months later, half those features are either unused or need to be rebuilt because the market shifted and users wanted something different. The team hit their schedule. They failed their users.

Scrum prevents this by building in regular inspection points — the Sprint Review being the primary one — where stakeholders see real working software and provide real feedback. Forecasts get updated. The Product Backlog gets reordered. The team builds the right thing, not just the planned thing. For exam purposes, remember this: Scrum doesn't eliminate planning, it makes planning continuous and evidence-based.

---

Techniques for Forecasting Progress and Completion Dates

When a stakeholder asks "when will this be done?" — and they will — the Scrum Team needs tools to give an honest, data-grounded answer. Scrum doesn't prescribe specific forecasting techniques, but the PSM I and CSM exams expect you to understand the most widely used ones.

Velocity

Velocity is the most common forecasting tool in Scrum. It measures how much work (typically in Story Points or similar relative units) a team completes per Sprint. After several Sprints, velocity stabilizes into a range, and the team can use that range to project future Sprints.

For example, if a team consistently completes 30–40 points per Sprint, and the Product Backlog contains 200 points of prioritized items, you can forecast roughly 5–7 Sprints to complete that scope. That's a meaningful planning signal — not a promise.

Exam mindset: Velocity belongs to the Developers, not the Scrum Master or Product Owner. Management using velocity to pressure teams or compare teams is an anti-pattern. Scrum Masters actively protect velocity data from being weaponized.

Burn-down and Burn-up Charts

• Sprint Burn-down chart: Tracks remaining work within a single Sprint. Shows whether the team is on track to meet the Sprint Goal.
• Release Burn-down chart: Tracks remaining Product Backlog items (or points) across multiple Sprints toward a release goal.
• Burn-up chart: Shows cumulative work completed and total scope, making scope changes visible — which is often more honest than a burn-down.

The Scrum Guide doesn't mandate any specific chart. What it does require is that progress toward the Product Goal and Sprint Goal be tracked and made transparent. How teams do that is up to them.

The Importance of Refinement in Forecasting Accuracy

Forecasts are only as good as the backlog they're based on. Product Backlog Refinement — the ongoing process of breaking down and estimating items — is what keeps forecasts meaningful. If the top items in the backlog are too large or poorly understood, velocity-based forecasts become unreliable. Scrum Masters facilitate and protect time for refinement as a direct investment in forecasting quality.

---

The Role of the Product Owner in Release Planning

The Product Owner sits at the intersection of the Scrum Team and its stakeholders. When it comes to release planning, they carry significant responsibility — but within specific boundaries that the exam tests carefully.

The Product Owner is accountable for Product Backlog management: ordering items, ensuring they're sufficiently refined, and communicating the Product Goal. In release planning, this translates to decisions like: Which items must be in the release? What's the minimum viable product that delivers real value? Which items can be deferred without compromising the goal?

Balancing Value, Risk, and Stakeholder Input

A skilled Product Owner doesn't just order the backlog by stakeholder priority. They balance value (what delivers the most benefit to users), risk (what unknowns could derail the release), and learning (what assumptions need to be validated early). This ordering directly impacts what the team builds and when a meaningful release can happen.

During Sprint Planning, the Product Owner presents items from the Product Backlog and collaborates with the Developers to determine what can reasonably be selected. The Developers — not the Product Owner — determine how much work they can take on. This is a critical distinction for the exam: the Product Owner doesn't set Sprint capacity. They communicate what's most valuable, and the Developers self-manage the "how" and "how much."

Real-world tip: Product Owners often face pressure from stakeholders to commit to specific release dates. The mature response is to share the current forecast based on velocity and backlog size, explain what factors could accelerate or delay it, and commit to transparency rather than false certainty.

---

Managing Stakeholder Expectations with Empirical Data

One of the less glamorous but critically important parts of a Scrum Master's job is helping stakeholders shift their relationship with uncertainty. Most stakeholders want dates. They have budgets to approve, marketing campaigns to plan, and contracts to negotiate. Telling them "it depends" feels unsatisfying.

The Scrum Master's role here is servant leadership in action: educate stakeholders on how empirical forecasting works, facilitate their participation in Sprint Reviews where they see real progress, and help the organization develop tolerance for adaptive planning.

Turning the Sprint Review Into a Planning Tool

Sprint Reviews are not just demos. The Scrum Guide describes them as working sessions where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog accordingly. This is where stakeholders get actual visibility into what's been built, raise concerns, reprioritize, and update their own expectations.

A well-run Sprint Review gives stakeholders more reliable information than any upfront Gantt chart could. They've seen working software. They've given feedback. The forecast is based on demonstrated progress, not assumptions made months ago.

Communicating Forecasts Without Overpromising

• Share velocity trends, not point-in-time numbers
• Present forecast as a range ("based on current velocity, we're forecasting delivery in 6–9 Sprints")
• Explicitly name assumptions the forecast depends on ("this assumes scope stays approximately stable and team composition doesn't change")
• Update forecasts after every Sprint Review, not just at the start of a release

---

Common Exam Questions on Velocity and Burn-down Charts

This is where candidates drop points unnecessarily. Let's go through the key exam traps.

Question type 1: "Who owns velocity?" The correct answer is always the Developers. Velocity is a planning tool for the team, not a performance metric for management.

Question type 2: "A Scrum Master notices velocity has dropped three Sprints in a row. What should they do?" The Scrum Master should facilitate a conversation to inspect why — impediments, scope creep, team instability, unclear Sprint Goals. They don't set a target velocity or pressure the team to increase it.

Question type 3: "The burn-down chart shows the team won't complete all Sprint Backlog items. Who decides what to remove?" The Developers, in collaboration with the Product Owner to understand relative priority. The Scrum Master doesn't make this call, and management certainly doesn't.

Question type 4: "A manager asks for historical velocity data to compare two Scrum Teams. What should the Scrum Master do?" Push back respectfully. Velocity is context-specific — team size, story point calibration, and work type all vary. Comparing velocities across teams is misleading and creates harmful competition.

---

The Difference Between Forecasting and Commitment

This distinction shows up on nearly every PSM I exam in some form, and getting it wrong is a very common mistake.

A forecast is the team's current best estimate of when something will be done, based on empirical data and stated assumptions. It's expected to change as new information emerges. A commitment in Scrum is reserved for the Sprint Goal — the team commits to doing their best work toward a specific outcome within the Sprint.

Scrum specifically moved away from teams "committing to" a Sprint scope (the old language) because it created a culture of overpromising and underdelivering, or sandbagging to ensure "commitments" were met. The 2020 Scrum Guide replaced "commitment" at the Sprint level with "forecast," which is a meaningful philosophical shift.

Why this matters for the exam: Questions that ask you to choose between a team "committing to completing all selected Sprint Backlog items" versus "forecasting they can complete the selected items" — always choose forecast. The team commits to the Sprint Goal, not to every task on the board.

---

Best Practices for Tracking Progress Toward the Product Goal

The Product Goal, introduced in the Scrum Guide 2020, is the long-term objective that the Product Backlog exists to address. Tracking progress toward it requires a different lens than tracking Sprint velocity.

Linking Sprints to Outcomes

Every Sprint should contribute something meaningful toward the Product Goal — even if the contribution is learning that a particular approach doesn't work. Scrum Masters can help teams make this connection explicit during Sprint Planning ("how does what we're selecting this Sprint move us toward the Product Goal?") and during the Sprint Review ("what did we learn this Sprint that changes our view of the Product Goal?").

Metrics That Actually Matter

• Outcome-based metrics: User adoption, customer satisfaction, business value delivered
• Process health metrics: Sprint Goal achievement rate, refinement cadence, impediment resolution time
• Predictability indicators: Velocity trend stability, Sprint Backlog completion rate

Avoid the trap of treating velocity as a proxy for value. A team delivering 60 points per Sprint of low-value features is less effective than a team delivering 30 points of high-impact work.

---

Key Takeaways

• Scrum uses empiricism — transparency, inspection, adaptation — rather than rigid upfront plans
• Forecasts are based on real team performance data and are expected to evolve
• Velocity is a Developers' planning tool, not a management performance metric
• The Product Owner manages the Product Backlog and balances value, risk, and stakeholder needs — but doesn't set team capacity
• The Sprint Backlog represents a forecast, not a commitment; the Sprint Goal is what the team commits to
• Burn-down and burn-up charts support transparency but are not mandated by the Scrum Guide
• Stakeholder expectations are managed through transparency, Sprint Reviews, and honest range-based forecasting
• The difference between "forecast" and "commitment" is tested heavily on the PSM I exam

---

The concepts in this article become much clearer — and stick much longer — when you practice applying them to real scenarios. If you've been reading through the Scrum Guide and feel like you understand it conceptually, the next step is putting that understanding under pressure with scenario-based Scrum Master questions that mirror actual exam conditions. Many candidates are surprised to find that they understood the principles but misread the context in tricky exam questions. Regular practice with realistic scenarios closes that gap faster than any amount of re-reading.

---

Frequently Asked Questions

Q: Does the Scrum Guide 2020 require teams to use Story Points for estimation?

No. The Scrum Guide doesn't prescribe any specific estimation technique. Story Points are popular because they're useful, but teams can use any relative or absolute sizing method that gives them reliable enough data for forecasting. What matters is consistency within the team, not the unit of measurement.

Q: How many Sprints of velocity data do you need before forecasts become reliable?

Most practitioners suggest at least three to five Sprints before velocity stabilizes enough to be meaningful for release planning. Early Sprints often have inflated or deflated velocity due to team formation effects, unclear Definition of Done, or unrefined backlog items. The Scrum Master plays a key role in ensuring the conditions are right for velocity to stabilize naturally.

Q: Can the Product Owner change the Sprint Goal mid-Sprint if stakeholder priorities shift?

No. The Sprint Goal is fixed for the duration of the Sprint and should only be abandoned in exceptional circumstances — typically when conditions change so dramatically that the Sprint Goal becomes obsolete. This is one of the core protections that allows Developers to self-manage and focus. The Product Owner communicates urgency through the backlog and the next Sprint, not by intervening in an active Sprint. Scrum Masters actively protect the team from mid-Sprint disruptions, including those coming from the Product Owner.