Scrum, day 14: what can change during a Sprint

Today's objective: distinguish a useful adaptation of Sprint work from a change that endangers the Sprint Goal, and explain when cancellation is appropriate.

Read alongside: the Sprint section of the Scrum Guide and Scrum: A Pocket Guide, fourth edition, §3.7, “Sprint length.” Allow roughly five minutes for this companion, plus the assigned reading.

Keep a purpose steady while learning how to achieve it

The fictional ShiftSwap team is working toward a Sprint Goal: employees at the second café can understand a declined request and choose a valid next step without asking the manager to interpret the outcome.

The Developers' initial plan includes displaying a readable reason, explaining the available actions, and adding a shortcut for inviting another eligible colleague. On the fourth working day, they discover that some older requests contain internal notes that should not appear as employee-facing explanations.

They also receive an unrelated request to refresh the application's branding for a presentation. Both developments are new information. They have very different relationships to the Sprint Goal.

The Sprint provides a stable interval in which the team can pursue a coherent purpose, create a usable result, and inspect what it learns. Stability of purpose does not require pretending the initial plan contains every task that will be needed.

Evaluate the discovery against the goal

Handling internal notes correctly is necessary for a trustworthy decline explanation. The Developers need to investigate the affected data and decide how older requests should behave. Ignoring the discovery would put the intended result at risk.

They discuss a scope adjustment with Elena, the Product Owner. Perhaps the first version can show the explanation and a clear next step while leaving the automatic invitation shortcut for later. The employee would still understand what happened and how to proceed, if the simpler flow is genuinely usable.

That qualification matters. Removing every next-step option and calling the remaining label “close enough” might undermine the goal. The team must inspect the actual result, rather than treating scope reduction as automatically acceptable.

Scrum.org's Sprint reference describes the relevant boundaries: protect the Sprint Goal, maintain quality, and discuss scope with the Product Owner as more is learned. Those boundaries allow adaptation while keeping the purpose meaningful.

Make the cost of an interruption visible

The branding request may matter to the sponsor, but the team needs to understand its urgency and consequence. Elena asks which presentation depends on it and whether the existing appearance prevents the required conversation.

The Developers explain what interrupting the decline work would affect. If the new request would endanger the Sprint Goal, inserting it quietly is not a harmless act of responsiveness. The sponsor needs an honest account of that trade-off.

The request can be considered for the Product Backlog. If a genuinely urgent need emerges, the team should discuss it promptly with the relevant people. “The Sprint has started” is insufficient reasoning on its own; so is “a senior person asked.” The decision needs to account for the goal, the consequences, and what has changed.

The Developers' plan can also adapt without changing selected product scope. Pairing on the data problem, changing implementation order, or bringing verification earlier may improve the chance of achieving the same result.

Preserve the meaning of Done

The team considers omitting the old-request checks to meet its initial forecast. Those checks are necessary to establish that the new behavior handles the records included in its intended use. Skipping them would hide uncertainty about the result's quality.

A responsible scope choice might exclude an older class of requests from the new flow and handle it explicitly through a safe existing path. Whether that is acceptable depends on the user experience and the goal. It must be an intentional product decision with the relevant behavior verified.

By contrast, declaring unexamined behavior acceptable because the Sprint is ending weakens the shared quality boundary. The timebox makes the remaining work visible; it does not turn incomplete work into an Increment.

Distinguish an obsolete goal from a difficult goal

Now consider a different development. The second café decides to stop permitting employee-initiated swaps because it is closing permanently. The current Sprint Goal may no longer have a useful audience. Elena needs to assess whether pursuing it still makes sense.

The Scrum Guide gives the Product Owner authority to cancel a Sprint when its goal becomes obsolete. Other people can supply the information behind that decision. A Developer does not independently cancel the Sprint because an estimate was wrong, and a sponsor does not simply replace the goal halfway through it.

Difficulty completing a goal is different from the goal losing its relevance. If the work remains valuable but turns out to be harder than expected, the team should make the situation transparent and adapt responsibly. Cancellation should not be used to erase an uncomfortable forecast.

Let the timebox reveal the actual result

ShiftSwap uses a two-week Sprint in this example. It does not extend the Sprint by several days to make the initial task list appear complete. At its conclusion, the team can inspect what is actually Done, progress toward the goal, and the implications of any unfinished work.

Unfinished work returns to the Product Backlog for consideration. It does not automatically become the next Sprint's highest-priority commitment. New information may change its order, size, or usefulness.

Useful Increments can also be delivered before the Sprint ends. The boundary establishes a dependable inspection rhythm; it does not require the team to batch all value into one release on the final afternoon.

Classify three changes

Consider the internal-note discovery, the branding request, and the café closure. For each, write what changed, how it relates to the Sprint Goal, who needs to participate in the decision, and which options remain available.

Then apply the same questions to a recent interruption in your own work. Be explicit about whether the goal remained worthwhile, whether scope could change, and whether the quality standard was preserved.

Reflection: when your team says it needs flexibility, which part of the plan does it want to change? Naming that part makes it easier to distinguish useful adaptation from losing the purpose of the Sprint.

The next companion returns to Sprint Planning and examines how to establish that purpose before selecting the work.