The Must-Have That Arrived on Wednesday
Northline Retail's checkout team has six Developers and two-week Sprints. On Monday the team agreed a Sprint Goal: 'A returning customer can pay with a saved card on mobile web.' On Thursday morning, day four, the sales director tells the Product Owner that a competitor has launched one-click reordering and that the board meets in ten days. The Product Owner adds three new Product Backlog items to the Sprint Backlog and tells the team to 'fit them in'. The team is midway through a payment-token refactor that the saved-card work depends on. One Developer proposes dropping the saved-card item to the next Sprint so the new items can start; another says the team will 'work evenings'. The Product Owner replies that Scrum is supposed to be responsive and that, as Product Owner, they own the Sprint Backlog and can change it. Six working days remain in the Sprint.
1. Is the Product Owner correct that they can change the Sprint Backlog mid-Sprint? State precisely what Scrum says, including the limits.
Read the worked answer
Partly right about the goal, wrong about ownership of the Sprint Backlog.
What Scrum actually specifies:
- The Product Owner is accountable for maximising value and for ordering the Product Backlog. That is where the new competitive information belongs first.
- The Sprint Backlog is a plan by and for the Developers. They own it and adapt it daily as they learn. The Product Owner does not edit it unilaterally.
- Scope may be clarified and renegotiated with the Product Owner as more is learned. So change is not forbidden - the constraint is that scope must not change in a way that endangers the Sprint Goal.
- The Sprint Goal is a commitment the team makes at Sprint Planning. It is not renegotiated mid-Sprint. If it becomes obsolete, only the Product Owner can cancel the Sprint, and obsolescence is the only valid reason.
Applying that here: adding three items on day four with six days left, while the team is inside a dependency-heavy refactor, is precisely a change that endangers the Sprint Goal. Saying 'we will work evenings' is not a capacity plan; it is a loan against the next Sprint's quality and the team's sustainability.
The correct framing for the Product Owner is: you control what the team works on next and whether to cancel this Sprint. You do not control how the team plans within the Sprint.
2. A competitor launch has genuinely shifted priorities. What options should the Scrum Master put to the Product Owner and the Developers, and which would you recommend?
Read the worked answer
Lay out the real options rather than arbitrating between 'yes' and 'no'.
- Protect the Sprint Goal and defer. The new items go to the top of the Product Backlog, get refined, and start next Sprint. Cost: up to six days of delay on the reordering work. Benefit: one finished, integrated capability and no half-built refactor.
- Trade scope inside the goal. Remove smaller saved-card scope to buy capacity, keeping the Sprint Goal intact. This only works if the goal can still be met. Given the goal is literally saved-card payment, dropping that item is not a trade - it is abandoning the goal.
- Cancel the Sprint. Valid only if the Product Owner judges the Sprint Goal obsolete. That is a real option when a competitor move genuinely invalidates the increment. The costs are concrete: lost work, a re-planning session, disruption to the refactor, and a message to stakeholders. It is not free, so it must be a deliberate decision, not a reflex.
- Negotiate the external commitment, not the Sprint. The board deadline is a stakeholder expectation about a Product Goal, not a Scrum event. The Product Owner can reshape what is shown at the board meeting.
Recommendation: test option 3 honestly, then default to option 1. Competitor activity is almost never automatic obsolescence of a specific Sprint Goal, and the Sprint Review in six days is the natural forum to show the saved-card increment and agree the reordering priority with stakeholders in the room.
3. How should the Scrum Master handle the 'we will work evenings' offer and the pressure coming from the sales director?
Read the worked answer
Both are impediments to surface, not behaviours to scold.
The evening offer is a signal that the team believes the only acceptable answer is yes. If the Scrum Master lets it stand, the Sprint may appear to succeed while hiding a predictable quality cost and a future velocity collapse. Two concrete moves:
- Make the trade-off explicit in numbers. With six Developers and six remaining days, capacity is roughly 36 person-days before leave and support work. The three new items plus the existing goal cannot fit. Put that on a whiteboard and let the Product Owner choose with the arithmetic in view.
- Refuse to treat overtime as capacity. Ask what will not be done instead, or what will be done less well. Sustainable pace is not comfort; it is the condition for the transparency the Product Owner needs.
With the sales director: the Scrum Master does not fight the Product Owner's stakeholder. Coach the Product Owner to manage upward - go back to the sales director with a dated commitment derived from the backlog ordering and a demo invitation, not a flat refusal. Escalate only if the organisation's norm becomes 'escalate to the team and they will absorb it', because that pattern will repeat every Sprint and is an organisational impediment, not a one-off conversation.