skip to content

Who may change the Sprint Backlog when unforeseen work appears mid-Sprint, and what may not change?

level: seniorimportance: must knowfreq 60%

answer

  1. The Developers own their own plan
  2. A forecast, not a signed agreement
  3. One thing stays fixed all Sprint
  4. Scope negotiable, goal preserved
  5. Only one accountability may cancel a Sprint

basics

~20 s

Only the Developers change the Sprint Backlog, and they do so throughout the Sprint as they learn. The plan and the selected scope are theirs to revise; the Sprint Goal is the fixed point the revisions must preserve.

solid answer

~50 s

The Sprint Backlog belongs to the **Developers**. They add newly discovered work, drop items that turned out not to serve the goal, and change approach at any time during the Sprint — no approval required, because you cannot hold a group accountable for an outcome while someone else edits their plan. What is not theirs to move casually is the **Sprint Goal**. Scope inside the Sprint is negotiable with the Product Owner as more becomes known; the goal is what that negotiation preserves. If new work would make the goal unreachable, the honest response is a conversation about the goal, not a silent rewrite of the plan. Work that arrives from outside goes to the Product Owner and the Product Backlog. Only the Product Owner may cancel a Sprint, and only when the goal itself has become obsolete.

code

pseudocode · 17 lines
pseudocode
SPRINT BACKLOG   (owned by the Developers)

  SPRINT GOAL
    operators can save and recall a lighting scene without the
    scheduling system that is being decommissioned

  SELECTED ITEMS
    scene capture on the controller      complete
    scene recall on the operator console in progress
    migrate 43 stored scenes             waiting on peer review, 2 days

  PLAN, AS CHANGED ON DAY 4 BY THE DEVELOPERS
    + investigate undocumented format of the 43 stored scenes
    - separate scene-export screen (does not serve the Sprint Goal)

  UNCHANGED
    the Sprint Goal

go deeper

for a junior

Be ready to say that the Developers own the Sprint Backlog and update it throughout the Sprint, and that the Sprint Goal stays put. Knowing who may not change it matters as much as knowing who may.

for a middle

Explain the mechanics: the plan is a forecast revised as knowledge arrives, selected scope is negotiable with the Product Owner, and new outside work goes to the Product Backlog. Say why accountability requires the Developers to own their own plan.

for a senior

Bring a real case. Describe unforeseen work you hit mid-Sprint, what you added and dropped, when you told the Product Owner and why, and how you kept the goal intact instead of quietly redefining it as whatever shipped.

for a principal

Own the organisational side. Mid-Sprint interruption is usually a systems problem, not a discipline problem: be ready to discuss where unplanned demand originates, how you make it visible, and what you changed so protecting a goal did not depend on one team saying no.

## Ownership is defined per artifact Each Scrum artifact has one clear answer to "who may change this", and mixing them up is the source of most process arguments a team will have. | Artifact | Who may change it | Who is accountable | What that protects | | --- | --- | --- | --- | | Product Backlog | Anyone may propose; changes go through the Product Owner | Product Owner | A single, coherent order for the product | | Sprint Backlog | The Developers, at any time during the Sprint | The Developers | The team's ability to re-plan on new information | | Increment | Nobody edits it retroactively; new work adds to it | The Developers | The meaning of "complete" | The rule for the Sprint Backlog is deliberately narrow: it is the Developers' artifact. A Product Owner, a manager or a stakeholder may ask, argue and persuade, but none of them may reach into the plan and rewrite it. That is not territorial etiquette — it is what makes the Developers able to be accountable for the Sprint Goal at all. You cannot hold a group responsible for an outcome while someone else edits their plan. ## The Sprint Backlog is a plan, not a contract The Sprint Backlog is a **forecast plus a plan**: the Developers' best current understanding of what will meet the Sprint Goal and how. Plans made in ignorance get better as the ignorance recedes, so the Sprint Backlog is expected to change throughout the Sprint. Adding a newly discovered task, dropping an item that turned out to be unnecessary, or swapping an approach are all normal — none of them is a failure, and none of them requires ceremony. What may **not** move casually is the **Sprint Goal**. The goal is the fixed point the plan orbits. Scope inside the Sprint is negotiable between the Developers and the Product Owner as more is learned; the goal is what the negotiation must preserve. If new work would make the goal unreachable and cannot wait, the honest move is a conversation with the Product Owner about the goal itself, not a silent rewrite of the plan. ## A worked example A team on a stage-lighting control product takes a Sprint Goal: operators can save and recall a lighting scene without the scheduling system being decommissioned in parallel. On day 4 they find that the 43 stored scenes use an undocumented format, which nobody foresaw. What they do: - **Add** a short investigation of the stored format to the Sprint Backlog. Their own artifact, their own decision, no approval needed. - **Drop** a separate scene-export screen from the plan. It was selected, but it does not serve the Sprint Goal, and dropping it buys the time the investigation costs. - **Tell** the Product Owner the same day — not to ask permission for the re-plan, but because the dropped item is a change to what the Sprint is likely to deliver, and hiding it would make the artifact opaque. - **Keep** the Sprint Goal exactly as it is. Scene save and recall still ship; the route to them changed. What they do **not** do: accept a request that arrives on day 6 to also migrate the old scheduling rules. It is real work, and it belongs in the Product Backlog for the Product Owner to order — the Sprint's plan is theirs to change, but its capacity is not a queue anyone outside can push into. ## Edge cases interviewers probe 1. **A stakeholder inserts work directly.** The item goes to the Product Owner and the Product Backlog. Accepting it quietly is the single most common failure here, and it teaches everyone that the goal is optional. 2. **The Product Owner reorders the Product Backlog mid-Sprint.** Entirely allowed — that artifact is theirs. It does not change the current Sprint Backlog, which was already selected. 3. **The Sprint Goal becomes obsolete.** If the goal no longer makes sense — the product direction changed, the market moved — the Sprint may be cancelled, and only the Product Owner may cancel it. That is the deliberately expensive escape hatch, and its rarity is the point. 4. **The Developers want to add a large item late.** Allowed by ownership, unwise by judgment: the test is whether it serves the Sprint Goal, not whether the team has hours left. ## Why this design holds up The split gives one artifact to the accountability that must protect coherence for the product (the Product Owner and the Product Backlog) and one to the accountability that must deliver something usable this Sprint (the Developers and the Sprint Backlog). The Sprint Goal is the contract between them, and it is written once and defended, while everything underneath it is allowed to be wrong and get corrected. A team that treats the selected item list as the contract gets the opposite: a plan defended past the point of usefulness and a goal quietly abandoned.

  • A stakeholder asks the Developers directly to add work mid-Sprint. What do you do?
    Route it to the Product Owner for the Product Backlog rather than accepting it into the plan. Taking it quietly is the common failure: it teaches everyone that the Sprint Goal is optional and that capacity can be claimed by whoever asks most persistently. The Developers own their plan, but the Sprint's capacity is not an open queue.
  • When is changing the Sprint Goal itself the right call?
    When it has become obsolete — the direction changed, or what the goal assumed turned out to be false. That is not a plan adjustment, so it is a conversation with the Product Owner, who may cancel the Sprint. The escape hatch is deliberately expensive; a goal renegotiated whenever it gets hard stops being a fixed point at all.
  • The Developers realise on day 2 that they selected far too much. What changes?
    They drop items, keeping whatever still serves the Sprint Goal, and tell the Product Owner the same day because the likely delivery changed. Removing selected scope is a normal use of their own artifact. Working unsustainably to defend an item list they chose in ignorance is the worse answer, and interviewers listen for it.

saying these in an interview costs you the question

  • Says the Product Owner may edit the Sprint Backlog directly
  • Treats the Sprint Backlog as frozen once the Sprint starts
  • Changes the Sprint Goal to match whatever was finished
  • Accepts stakeholder requests straight into the current Sprint
  • Calls the selected item list a contract with stakeholders