Three days before the Sprint ends
A software vendor in Bitola is building a citizen-services portal for a public agency. You are the Scrum Master of a team of seven.
Three days before the end of a two-week Sprint, the Developers tell you in the Daily Scrum that the Sprint Goal - a working document-upload flow - cannot be reached: the agency's test environment was down for four days and two of the remaining items depend on it.
The Product Owner has already promised the agency a demo on Monday. They want the team to work the weekend and ask you to "get them to commit". A senior developer suggests moving the end of the Sprint by three days instead.
As the Scrum Master, what should you do first?
Pick the option that looks best to you, then reveal the answer.
Reveal the answer
Best answer
BFacilitate a conversation between the Product Owner and the Developers about which items in the Sprint Backlog can be renegotiated so that the Sprint Goal - or its most valuable part - is still met, without changing the end of the Sprint.
The scope of the Sprint Backlog can be renegotiated with the Product Owner as more is learned; the Sprint Goal is what stays protected, and the Sprint's length is fixed. Making that conversation happen, today, is the Scrum Master's job.
Two rules of Scrum meet here, and the answer depends on knowing which one bends. The Sprint's duration does not: once a Sprint starts, it ends when it ends, so extending it is out no matter who caused the delay. The Sprint Backlog does: as the Developers learn more, the scope can be clarified and renegotiated with the Product Owner, as long as the Sprint Goal is protected. The Scrum Master's role in that negotiation is to make it happen - not to decide it, not to make the team accept overtime, and not to hand it to a director. A demo on Monday of the part of the upload flow that works, honestly labelled, is a better outcome for the agency than a weekend of tired people building against an environment that may go down again.
Why the other options are tempting but wrong
A. The Product Owner is accountable for the value of the product, not for the team's working hours, and the Scrum Master is not a channel for pushing overtime onto Developers. Weekend work solves this Sprint and creates the next problem; sustainable pace is a principle, not a perk.
C. Once a Sprint begins, its length does not change - not for the customer's fault, not for anyone's. The senior developer's suggestion is reasonable engineering and wrong Scrum: an extended Sprint makes the cadence unpredictable and hides the impediment that caused the delay instead of exposing it.
D. Removing the impediment is genuinely your job - but it is a parallel action, not a substitute for the decision the team needs before Monday. Escalating first hands the problem upward, fixes nothing in the next three days and skips the conversation the Product Owner and Developers should be having.
Where this sits in PMI
Scrum Guide (2020): the Sprint ("no changes are made that would endanger the Sprint Goal", "the scope may be clarified and renegotiated with the Product Owner as more is learned"), the Sprint Goal, the Scrum Master as a servant-leader. Agile Practice Guide, servant leadership. PMBOK Guide 7th ed., principle "Team".
Exam Content Outline tasks (PMP ECO) · 2026
- People 3 - Lead the project team
- Business Environment 4 - Remove impediments and manage issues
- Process 3 - Help ensure value-based delivery
PMP, PMBOK and PMI are registered marks of the Project Management Institute, Inc. The dilemmas are not PMI material and do not replace the official PMP Examination Content Outline.