Can the Sprint Backlog change during the Sprint?

Yes. It is a living plan that Developers update as they learn more, as long as changes still support achieving the Sprint Goal.

What stays stable vs. flexible during a Sprint?

The Sprint Goal is normally stable; the scope (selected items and tasks in the Sprint Backlog) is flexible and can be adapted.

Sprints are the heartbeat of Scrum, where ideas are turned into value.

An Increment is a concrete stepping stone toward the Product Goal.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Artifacts II: Sprint Backlog, Sprint Goal, and Adapting the Plan — Professional Scrum Master I (PSM I) Complete Exam-Ready Mastery Course

From Product Backlog to Sprint Backlog

Zooming Into the Sprint

You now zoom in on what happens at the start of a Sprint: how Developers turn selected Product Backlog items into a living Sprint Backlog anchored by a Sprint Goal.

Artifacts Connection

The Product Backlog spans the whole product and Product Goal. The Sprint Backlog focuses only on the current Sprint, turning ideas into a concrete short‑term plan.

Canonical Definitions

You must know: "The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)."

You must also know: "The Sprint Goal is the single objective for the Sprint." Expect exam questions that subtly change or omit parts of these phrases.

Ownership and Adaptation

At Sprint Planning, the Scrum Team creates a Sprint Backlog that is owned by Developers, is highly visible, and is updated throughout the Sprint as more is learned.

Current Reference

As of 2026, the current reference is the Scrum Guide 2020. Any prep that treats the Sprint Backlog as a fixed contract is outdated for PSM I.

Deep Dive: The Sprint Backlog (Why, What, How)

The Full Definition

Memorize: "The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)."

The Why: Sprint Goal

The Sprint Goal gives the Sprint its purpose. It answers: If we only achieve this one thing, is the Sprint still valuable? It guides trade‑off decisions.

The What: Selected PBIs

Selected Product Backlog items are pulled into the Sprint during Sprint Planning. They define the current expected scope, not a rigid contract.

The How: Actionable Plan

The actionable plan is the how: tasks, sub‑tasks, or steps. It must be detailed enough that Developers can inspect progress every day and adapt.

Common Exam Trap 1

If a question defines the Sprint Backlog only as "a list of selected Product Backlog items", it is incomplete. It must also include the Sprint Goal and plan.

Common Exam Trap 2

If a question says the Product Owner selects all Sprint Backlog items, it is incorrect. The Product Owner sets direction, but Developers select what they can do.

Deep Dive: The Sprint Goal as the Single Objective

Definition to Memorize

Know this exactly: "The Sprint Goal is the single objective for the Sprint." It is a commitment tied to the Sprint Backlog in Scrum Guide 2020.

Single Objective, Many Items

Single objective does not mean one item. It means a unifying outcome or theme that gives coherence to multiple Product Backlog items.

Created by the Scrum Team

The whole Scrum Team creates the Sprint Goal in Sprint Planning. It provides focus and a shared sense of purpose for the Sprint.

Fixed Goal, Flexible Scope

The Sprint Goal is normally fixed during the Sprint. Scope (items and tasks) is flexible as long as the Sprint Goal remains achievable.

Example Goal

Example: "Customers can reset their password without contacting support." Multiple items can support this, and some can change or be dropped if needed.

Exam Trap

If a question claims you cannot change Sprint Backlog items after Sprint Planning, it conflicts with Scrum. You may change items while keeping the Sprint Goal.

Worked Example: Building a Sprint Backlog Around a Goal

Example Context

Product Goal: "Increase mobile app user retention by 15%." Top Product Backlog items include personalization, in‑app tips, sign‑up simplification, and dark mode.

Step 1: Sprint Goal

The Scrum Team agrees on a 2‑week Sprint Goal: "New users understand key features within their first session." This focuses on onboarding.

Step 2: Select Items

Developers pull: PBI 2 (in‑app tips), a new PBI (track onboarding completion), and part of PBI 3 (simplify key sign‑up steps) to support the Sprint Goal.

Step 3: Actionable Plan

Developers create tasks: design tips, implement carousel, add analytics events, refactor sign‑up validation, and update automated tests.

The Resulting Sprint Backlog

The Sprint Backlog now has: why (Sprint Goal), what (selected PBIs), and how (task plan). It is a living plan, not a frozen contract.

Exam Reminder

If a question shows a Sprint Backlog as only tasks or only items without a Sprint Goal, it is incomplete under the current Scrum Guide.

Developers’ Ownership of the Sprint Backlog

Who Owns the Sprint Backlog?

Developers own the Sprint Backlog. They are "committed to creating any aspect of a usable Increment each Sprint" and control the plan.

They Create the Plan

In Sprint Planning, Developers decide how much work they forecast and how they will do it. The Product Owner brings ordering and goals, not the detailed plan.

They Update It Daily

Developers break down, add, remove, or reorder tasks as they learn. They may split Product Backlog items into smaller slices to stay on track.

They Own Progress

Developers use the Sprint Backlog at the Daily Scrum to inspect progress toward the Sprint Goal and adapt their plan for the next 24 hours.

What Ownership Is Not

Ownership does not allow the Product Owner, Scrum Master, or stakeholders to change the Sprint Backlog directly. They can influence but not override Developers.

Exam Traps

If you see "PO can change the Sprint Backlog anytime" or "SM updates the Sprint Backlog after the Daily Scrum", mark them as false for PSM I.

Adapting the Sprint Backlog During the Sprint

Living Plan, Not Contract

The Sprint Backlog is a living plan. It is expected to change as Developers learn more, consistent with Scrum being founded on empiricism and lean thinking.

Why It Changes

Developers adapt when they discover new technical insights, better approaches, feedback from testing, or when dependencies and blockers change.

What Can Change

Tasks can be added, removed, or adjusted. Items can be split or refined. Estimates can change, as long as the Sprint Goal remains achievable.

What Stays Stable

The Sprint Goal normally stays stable. Changing it usually means canceling the Sprint; minor scope changes do not justify a new Sprint Goal.

Example Adaptation

If a third‑party API is down, Developers remove dependent tasks, add fallback tasks, and talk with the Product Owner about whether the Sprint Goal is still realistic.

Exam Perspective

When new work appears mid‑Sprint, the right answer is usually: Developers and Product Owner adjust the Sprint Backlog while keeping the Sprint Goal in mind.

Transparency and the Daily Scrum

Daily Scrum Purpose

The Daily Scrum lets Developers inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours, using the Sprint Backlog as their main tool.

Visualizing Progress

A transparent Sprint Backlog shows which items are To Do, In Progress, and Done (per the Definition of Done), often via boards or charts.

Better Conversations

With a clear Sprint Backlog, Developers ask: Are we on track for the Sprint Goal? What is blocked? What is the most valuable thing to do next?

Stakeholder Insight

Product Owner and stakeholders can inspect the Sprint Backlog anytime to see likely outcomes, reducing surprises at the Sprint Review.

Exam Myths

Myths: Daily Scrum is for reporting to the PO, only the SM updates the Sprint Backlog, or the Sprint Backlog should be hidden. All are false.

Correct View

A transparent Sprint Backlog supports self‑management, empirical control, and honest communication within and beyond the Scrum Team.

Thought Exercise: Adjusting Scope Without Breaking the Goal

Use this scenario to practice thinking like a PSM I candidate.

Scenario

Sprint length: 2 weeks, day 6.
Sprint Goal: “Enable customers to download their purchase history as a PDF.”
Current Sprint Backlog items:

Implement backend endpoint to fetch purchase history.
Generate PDF from purchase data.
Add “Download PDF” button to order history page.
Add automated tests and update documentation.

On day 6:

Developers discover that the PDF library they chose has a serious security vulnerability.
Switching to a safe library will add 2–3 days of work.
They now doubt they can finish all tasks as planned.

Your task

Pause and think through these questions (mentally or jot down notes):

What is the Sprint Goal really about?

Is it tied to a specific library or to the user outcome?

What options do Developers have to adapt the Sprint Backlog while keeping the Sprint Goal?

Examples: dropping nice‑to‑have formatting, simplifying the PDF layout, deferring some documentation improvements.

Who should they collaborate with?

Hint: Product Owner for scope trade‑offs; Scrum Master for coaching if needed.

What would be an anti‑Scrum response?

Examples: secretly cutting quality below the Definition of Done, asking the Product Owner to change the Sprint Goal to “Investigate PDF libraries.”

After you have an answer, compare it to the next explanation step’s patterns: you should see that scope flexes, the Sprint Goal stays, and Developers drive the plan.

Quiz 1: Sprint Goal and Scope Flexibility

Test your understanding of Sprint Goal vs. scope during the Sprint.

Mid‑Sprint, Developers realize one selected Product Backlog item is much larger than expected. The Sprint Goal is still achievable if they drop that item and focus on others. What is the BEST action according to Scrum?

Keep all items; the Sprint Backlog cannot change once the Sprint has started.
Collaborate with the Product Owner to remove or adjust the item while keeping the Sprint Goal.
Ask the Scrum Master to extend the Sprint by a few days so all items can be finished.
Cancel the Sprint because any change in scope requires a new Sprint Goal.

Show Answer

Answer: B) Collaborate with the Product Owner to remove or adjust the item while keeping the Sprint Goal.

Scrum allows and expects the Sprint Backlog to change during the Sprint as more is learned, as long as the Sprint Goal remains achievable. Developers should collaborate with the Product Owner to adjust scope. The Sprint Backlog is not frozen (A is wrong), Sprints are never extended (C is wrong), and changing scope does not automatically require canceling the Sprint (D is wrong).

Quiz 2: Ownership and Transparency

Check who can change what, and how transparent the Sprint Backlog should be.

Who is responsible for updating the Sprint Backlog during the Sprint?

The Product Owner, because they are accountable for maximizing value.
The Scrum Master, because they are accountable for the Scrum process.
Developers, because they own the plan for delivering the Increment.
Stakeholders, because they request new features.