SkarpChapter 7 of 21
The Sprint: Heartbeat of Scrum and Container for All Work
Enter the Sprint as the fixed-length heartbeat of Scrum, explore its rules and constraints, and dissect tricky questions about changes, cancellation, and multiple Sprints.
The Sprint in One Sentence (and Why It Matters)
Sprint: The Canonical Definition
Memorize this: "Sprints are the heartbeat of Scrum, where ideas are turned into value." This is the official definition you will see echoed in exam-style questions.
Why Heartbeat Matters
Heartbeat means regular, predictable rhythm. Every Sprint has the same pattern: plan, work, inspect, adapt. This cadence lets the Scrum Team learn and adjust frequently.
Container for All Work
All Scrum events and all development work happen inside Sprints. There is no work that is "outside" a Sprint in Scrum. No separate analysis phase, no special hardening Sprint.
Ideas Into Value
Each Sprint should create at least one Increment: "a concrete stepping stone toward the Product Goal." That is how ideas from the Product Backlog become real value.
Exam Lens
When you see scenarios about planning, changes, or releases, check if they respect the Sprint as a fixed heartbeat and container for all work. If not, they are likely incorrect for PSM I.
Sprint Timebox and Cadence: One Month or Less
Timebox: One Month or Less
A Sprint is a fixed-length event of one month or less. Most teams choose 1 or 2 weeks, but anything up to 1 month is still Scrum-compliant.
Fixed Cadence
For a given Scrum Team, Sprint length should be stable. Constantly changing from 1 to 3 weeks and back erodes predictability and weakens empiricism.
Empiricism and Risk
Shorter Sprints mean more frequent inspection and adaptation. The 1‑month limit prevents long periods with no feedback, reducing risk and waste.
Events Inside the Sprint
Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective all happen within the Sprint. A new Sprint starts immediately after the previous one ends.
Exam Trap: Overlong Sprints
If a scenario proposes a 6‑week Sprint to "fit everything", that conflicts with Scrum. The right answer is to keep Sprints ≤ 1 month and slice work instead.
The Sprint as Container for All Work and Events
Sprint as a Container
Think of the Sprint as a box. Inside that box: the Sprint Goal, Sprint Backlog, all Scrum events, and the work that creates at least one Increment.
From Product Backlog to Sprint Backlog
The Product Backlog is "an emergent, ordered list of what is needed to improve the product." Selected items plus a plan become the Sprint Backlog.
Sprint Backlog Definition
The Sprint Backlog is "composed of the Sprint Goal (why), the set of Product Backlog items selected (what), and an actionable plan (how)."
Definition of Done Inside the Sprint
The Definition of Done is "a formal description of the state of the Increment when it meets the quality measures required for the product." All Increment work happens in the Sprint.
Exam Red Flag
If a scenario shows analysis before the Sprint and testing after, that breaks the idea of the Sprint as the container for all work. That setup is not Scrum.
Real-World Sprint Cadence Examples (And What the Exam Expects)
Team A: Healthy 2‑Week Cadence
Team A runs 2‑week Sprints with the same pattern each time. Planning at the start, Daily Scrums, Review and Retrospective at the end. This is textbook Scrum.
Team B: Changing Lengths
Team B keeps switching Sprint length from 1 to 4 weeks. Stakeholders are confused. On the exam, this unstable cadence is a problem the Scrum Master should address.
Team C: Overlong "Sprints"
Team C uses 6‑week Sprints. That breaks the one‑month limit. In PSM I terms, this is not Scrum; the team should shorten the Sprint.
Team D: Short Sprints, Many Releases
Team D has 1‑week Sprints and releases multiple times per Sprint. This is allowed; releases are not restricted to Sprint boundaries.
Exam Pattern
Look for answers that keep Sprints short and stable. Be suspicious of solutions that stretch the timebox or vary it to "match" feature size.
What Can Change During a Sprint (And What Cannot)
Stable Goal, Flexible Plan
The Sprint gives a stable window to pursue the Sprint Goal, but the plan can change. Scrum avoids chaos by protecting the goal while allowing scope negotiation.
Rule 1: Protect the Sprint Goal
The Sprint Goal is "the single objective for the Sprint." Changes that would make it obsolete or impossible should not be introduced mid‑Sprint.
Rule 2: Quality Cannot Drop
The Definition of Done still applies. You cannot lower quality mid‑Sprint (for example, skipping tests) just to deliver more scope.
Rule 3: Scope is Negotiable
Developers and the Product Owner can refine, split, or swap items as long as the Sprint Goal remains intact. The Sprint Backlog is a living plan.
Exam Signal
If a scenario shows big mid‑Sprint changes that destroy the Sprint Goal, the correct move is not to accept them blindly; it may lead to Sprint cancellation.
Thought Exercise: Mid-Sprint Change Scenarios
Work through these scenarios and decide what the Scrum Team should do. Think in terms of protecting the Sprint Goal, keeping quality, and allowing reasonable scope changes.
Scenario 1: Small change aligned with the goal
- Sprint Goal: "Enable customers to reset their password without contacting support."
- Mid-Sprint, a stakeholder asks: "Can we also send a confirmation email after a successful reset?" This clearly supports the same goal.
Your task:
- Would you accept this change into the Sprint Backlog?
- Under what condition is this acceptable in Scrum?
Reflect, then check yourself: It is acceptable if the Product Owner and Developers agree it fits, does not endanger the Sprint Goal, and the team can still meet the goal without compromising quality. They may drop or reduce other scope to make room.
---
Scenario 2: New direction that conflicts with the goal
- Same Sprint Goal as above.
- Mid-Sprint, the CEO says: "Stop working on password resets. We must build a new dashboard for sales metrics right now."
Your task:
- Can the CEO directly change the Sprint Backlog?
- What is the correct Scrum response?
Reflect, then check yourself: The CEO cannot change the Sprint Backlog directly. They can influence through the Product Owner. If the Product Owner agrees that the Sprint Goal is now obsolete, the Product Owner may cancel the Sprint and start a new one with a new goal.
Use this pattern on the exam: ask yourself whether the requested change supports or destroys the Sprint Goal, and whether the Product Owner is involved in the decision.
Sprint Cancellation: Who, When, and What Happens Next
Who Can Cancel a Sprint?
Only the Product Owner can cancel a Sprint. Others can suggest or influence, but they do not have the authority to cancel.
When to Cancel
A Sprint can be cancelled when the Sprint Goal becomes obsolete, for example due to market changes or a major new insight. It should be rare.
What Happens to the Work?
Work that is Done, according to the Definition of Done, becomes part of the Increment and can be released. Undone work returns to the Product Backlog.
After Cancellation
After cancelling, the Scrum Team starts a new Sprint as soon as possible, with a new Sprint Goal and a fresh Sprint Planning session.
Exam Traps
Beware options saying the CEO or Scrum Master cancels the Sprint, or that all work is discarded. Both conflict with the Scrum Guide.
Quick Check: Sprint Cancellation and Mid-Sprint Changes
Test your understanding of who can cancel a Sprint and what may change during a Sprint.
During a Sprint, a major competitor launches a feature that makes the current Sprint Goal irrelevant. The CEO demands immediate work on a new response feature. According to Scrum, what is the BEST action?
- The Scrum Master cancels the Sprint and schedules new Sprint Planning.
- The Product Owner cancels the Sprint if they agree the Sprint Goal is obsolete, then collaborates with the Scrum Team to start a new Sprint.
- Developers abandon the current Sprint Goal and start working on the CEO's request without changing the Sprint.
- The Sprint continues unchanged because Sprints can never be cancelled once they start.
Show Answer
Answer: B) The Product Owner cancels the Sprint if they agree the Sprint Goal is obsolete, then collaborates with the Scrum Team to start a new Sprint.
Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete. If the Product Owner agrees with the CEO that the goal is obsolete, they may cancel the Sprint and immediately plan a new Sprint. Developers cannot unilaterally abandon the Sprint Goal, and the Scrum Master cannot cancel the Sprint.
Multiple Sprints, Multiple Teams, and Releases
Sprints vs Releases
A Sprint is a fixed timebox for inspection and adaptation. A release is a business decision to deliver the Increment. Releases can happen during or at the end of a Sprint.
Multiple Teams, One Product
Several Scrum Teams can work on one product. They share one Product Backlog and Product Goal, but each has its own Sprint and Sprint Backlog.
Synchronized Sprints
For the same product, teams usually align Sprint length and dates. This makes integrated Increments and joint Sprint Reviews easier.
No Parallel Sprints for One Team
One Scrum Team cannot be in two Sprints at once. There are no nested or overlapping Sprints for a single team in Scrum.
Exam Hint
Be wary of answers that tie releases strictly to Sprint boundaries or suggest one team running multiple Sprints at the same time.
Quick Check: Sprints, Teams, and Releases
Confirm your understanding of how Sprints relate to releases and multiple teams.
Which statement is MOST consistent with Scrum as defined in the current Scrum Guide?
- A Scrum Team may run two overlapping Sprints if it helps deliver more features.
- All releases must occur at the end of a Sprint during the Sprint Review.
- Multiple Scrum Teams working on the same product should share one Product Backlog and can release whenever a Done Increment is available.
- Each Scrum Team working on the same product must have its own separate Product Backlog.
Show Answer
Answer: C) Multiple Scrum Teams working on the same product should share one Product Backlog and can release whenever a Done Increment is available.
Scrum allows multiple teams on the same product as long as they share one Product Backlog. Releases can occur whenever a Done Increment is available, not only at Sprint boundaries. A single team cannot be in multiple overlapping Sprints.
Key Sprint Concepts Review
Use these flashcards to lock in the exact wording and key rules around Sprints.
- Sprint (canonical definition)
- Sprints are the heartbeat of Scrum, where ideas are turned into value.
- Maximum Sprint length
- One month or less. The Scrum Team should keep Sprint length stable to support empiricism and predictability.
- Sprint Backlog (canonical definition)
- 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).
- Who can cancel a Sprint?
- Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete.
- What happens to Done work when a Sprint is cancelled?
- Work that meets the Definition of Done becomes part of the Increment and may be released; incomplete work returns to the Product Backlog.
- Can scope change during a Sprint?
- Yes. The Product Owner and Developers can clarify and renegotiate scope as long as changes do not endanger the Sprint Goal and quality does not drop.
- Sprint Goal (canonical definition)
- The Sprint Goal is the single objective for the Sprint.
- Definition of Done (canonical definition)
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Are releases tied to the end of the Sprint?
- No. Releases are business decisions. A Done Increment can be released at any time, including multiple times per Sprint.
- Multiple teams, one product
- Multiple Scrum Teams can work on the same product if they share one Product Backlog and Product Goal. Each team has its own Sprint and Sprint Backlog.
Exam-Style Scenario Lab: Spot the Sprint Violations
Apply what you have learned to short exam-style scenarios. For each, mentally decide: "Scrum-consistent" or "Not Scrum-consistent", and what the better answer would be.
Scenario A: Changing Sprint length for a big feature
A Scrum Team normally runs 2-week Sprints. A large feature is estimated at 7 weeks of work. Management decides to run a one-time 7-week Sprint to "avoid breaking the feature".
- Is this Scrum-consistent? Why or why not?
- What should the Scrum Master coach instead?
Self-check: Not Scrum-consistent. Sprints must be one month or less. The better approach is to keep the Sprint length and slice the feature into smaller Product Backlog items that still produce usable Increments.
---
Scenario B: Product Owner bypassed mid-Sprint
Mid-Sprint, a senior manager tells Developers to drop two items and start a new urgent item immediately. The Product Owner is not consulted.
- Is this Scrum-consistent?
- What should happen instead?
Self-check: Not Scrum-consistent. Only the Product Owner manages the Product Backlog and should decide what is in or out of the Sprint, in collaboration with Developers. The team should ask the manager to discuss priorities with the Product Owner.
---
Scenario C: Work outside Sprints
A team uses Sprints for coding but does all testing and deployment in a separate "hardening phase" every quarter, outside any Sprint.
- Is this Scrum-consistent?
- How should the Sprint be used differently?
Self-check: Not Scrum-consistent. The Sprint is the container for all work needed to create a Done Increment, including testing and deployment. Those activities should be brought into each Sprint.
Keep this habit for the mock exams: for any scenario, ask whether it respects the Sprint timebox, the authority of the Product Owner, and the idea that Sprints are the heartbeat of Scrum where ideas become value.
Key Terms
- Scrum
- Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
- Sprint
- Sprints are the heartbeat of Scrum, where ideas are turned into value.
- Release
- A business decision to make a Done Increment available to users. Releases can occur at any time and are not limited to Sprint boundaries.
- Increment
- An Increment is a concrete stepping stone toward the Product Goal.
- empiricism
- Scrum is founded on empiricism and lean thinking.
- Sprint Goal
- The Sprint Goal is the single objective for the Sprint.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Sprint Backlog
- 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).
- Product Backlog
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Definition of Done
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Sprint cancellation
- The act of ending a Sprint before its timebox is over. Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete.