The Regulatory Surprise on Day 12
Meridian Retail Bank runs Scrum in its payments domain. A team of six Developers is on day 12 of a 20-working-day Sprint. The Sprint Goal is 'card-dispute flow passes security review and can be deployed to staging'. On day 12 the regulator publishes a new authentication requirement that the Head of Digital calls 'non-negotiable for this release'. The Product Owner tells one Developer in a corridor to start on the new requirement immediately and to 'drop the security work if needed'. The Scrum Master is on leave until day 15. Meanwhile the Daily Scrum has drifted to 30 minutes, with the Head of Digital attending and asking each Developer what they did yesterday. At Sprint Planning the team selected items totalling 34 story points and has 22 points not yet Done. The team's last three Sprints delivered 30, 36 and 31 points.
1. The Head of Digital asks whether the Sprint can simply be extended by a week to absorb the new requirement. As the returning Scrum Master, what do you advise about Sprint length and Sprint cancellation, and what has to be true before a Sprint is cancelled?
Read the worked answer
Answer: the Sprint cannot be extended, and cancellation is a Product Owner decision with a strict test.
- Sprints are fixed-length by design. Extending one destroys the cadence, breaks the meaning of the forecast, and makes every future Sprint end date negotiable. Treat 'extend by a week' as not an option.
- Only the Product Owner can cancel a Sprint, and only when the Sprint Goal has become obsolete. Cancellation is rare and expensive, so it is a last resort, not a scheduling convenience.
- Apply the test honestly here: the Goal is 'security review passed and deployable to staging'. If the new authentication requirement means the Increment cannot pass security review, the Goal may genuinely be obsolete, and cancellation is defensible. If the Goal can still be met, cancellation is not justified.
- Mechanical consequences of cancellation: Done items are reviewed; if part of the Increment is potentially releasable, the Product Owner accepts it; all remaining Product Backlog items return to the Product Backlog (they are not discarded); the team runs Sprint Planning for a new Sprint with a new Sprint Goal; a Retrospective is held to learn from what happened.
What I actually do as Scrum Master: do not decide for the Product Owner. Facilitate a short session between the Product Owner and the Developers on day 15 with the facts on the table, and make the trade-off explicit. My role is to protect the timebox, explain the rule, and ensure the choice is made transparently rather than in a corridor.
2. Who owns the Sprint Backlog, and how should the Product Owner's corridor instruction to the individual Developer be handled?
Read the worked answer
The Sprint Backlog belongs to the Developers; the Product Owner owns the ordering of the Product Backlog, not the assignment of work to people.
- The Product Owner is accountable for maximizing value and for ordering the Product Backlog, and may legitimately bring the new requirement to the team. But the Developers decide what fits in the Sprint and how the work is done.
- The corridor instruction is an anti-pattern for three reasons: it assigns work to an individual rather than the team, it removes the trade-off from the people who must do the work, and it invites a Developer to unilaterally abandon the Sprint Goal (the security work).
- Correct handling: the Product Owner brings the item to the Developers; the Developers assess the impact on the Sprint Goal and propose options. Either the new item fits without endangering the Goal, or it does not. If it does not, the Product Owner chooses between waiting (item goes to the Product Backlog with an order) and cancelling the Sprint because the Goal is obsolete.
- The Sprint Goal is a commitment made by the Developers, so any renegotiation of it must involve them openly, not one Developer in a corridor.
Scrum Master action: coach the Product Owner on the boundary between ordering work and directing people; help the team re-plan visibly against the Sprint Backlog; protect the Developer from being placed in an impossible position; and if the pattern repeats, raise it in the Retrospective and with the Product Owner's manager as an organizational impediment.
3. What is wrong with the current Daily Scrum, and what should the Scrum Master do about the Head of Digital attending it?
Read the worked answer
The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is not a status meeting for a manager.
Symptoms in this case:
- It runs 30 minutes, double the timebox, which usually means it has become a reporting ritual rather than a planning conversation.
- The Head of Digital asking each Developer what they did yesterday converts inspection into upward reporting. Developers learn to justify themselves rather than to surface impediments, and honest bad news disappears.
- It displaces the real questions: are we on track for the Sprint Goal, and what do we change in the Sprint Backlog today?
What the Scrum Master does:
- Coach the Developers to own the event, its format and its timebox; the Scrum Master may attend to observe and coach but does not chair it.
- Coach the Head of Digital directly: explain the purpose of the Daily Scrum, that the team-level information he wants is visible in the Sprint Backlog and burn-up, and that his legitimate inspection point is the Sprint Review, where he can see the working Increment and give feedback.
- Do not turn this into a public confrontation during the event. Handle it before or after, then reinforce the norm with the team.
- If attendance persists, treat it as an impediment: discuss it in the Retrospective and escalate it as a self-management issue, not as a personality problem.