A Scrum Master observes that the Product Owner frequently changes the ordering of the Product Backlog during a Sprint, often in response to ad-hoc requests from various stakeholders. This leads to the Developers feeling disoriented and sometimes abandoning work-in-progress. What is the MOST appropriate way for the Scrum Master to address this situation?
- AAdvise the Developers to ignore changes to the Product Backlog once Sprint Planning is complete and focus only on committed items.
- BCoach the Product Owner on the importance of a stable Sprint Goal and protecting the Sprint Backlog once committed.
- CSuggest the Product Owner only present the Product Backlog to stakeholders during the Sprint Review to avoid mid-Sprint changes.
- DFacilitate a meeting with all stakeholders and the Product Owner to agree on a fixed Product Backlog for the duration of the Sprint.
Show answer & explanationAnswer & explanation
Correct answer: B. Coach the Product Owner on the importance of a stable Sprint Goal and protecting the Sprint Backlog once committed.
The Scrum Master's role involves coaching the Product Owner on Scrum principles. While the Product Backlog is dynamic, the Sprint Goal and the Sprint Backlog should remain stable after Sprint Planning to allow the Developers to focus. Coaching the Product Owner on protecting the Sprint Goal and the Sprint Backlog is crucial for team stability and focus.
Why the other options are wrong
- A. Developers should not ignore the Product Owner. While the Sprint Backlog is protected, any significant changes to the Product Backlog during a Sprint should be discussed and adapted in collaboration, not ignored.
- C. Limiting stakeholder interaction is counterproductive. The Sprint Review is for inspection and adaptation, and continuous stakeholder engagement is beneficial for the Product Owner to gather feedback and refine the Product Backlog.
- D. Fixing the Product Backlog for an entire Sprint is too rigid and goes against empiricism. The Product Backlog can (and should) change, but the Sprint Backlog and Sprint Goal should be protected.
Protecting the Sprint Goal
The Scrum Team commits to achieving the Sprint Goal. Once the Sprint Backlog is formed to achieve this goal, it should remain stable, and changes that endanger the Sprint Goal should be avoided.
- Provides focus and coherence for the Developers during the Sprint.
- The Product Owner protects the Sprint Goal from outside influence.
- Adaptations to the Sprint Backlog are allowed only if they don't endanger the Sprint Goal.
Memory trick: Sprint Goal as the anchor, Product Backlog as the sea.