The Sprint Goal That Wasn't
A Scrum team is midway through a two-week sprint. At the sprint review, the Product Owner announces that the team did not meet the Sprint Goal, which was to 'increase checkout conversion by 2%'. The team completed all the committed Product Backlog Items (PBIs) except one. During the sprint, they discovered that the original approach would not work and pivoted to a different solution that also improved conversion, but only by 1.5%. The Product Owner insists that the team failed because the goal was numeric and not met. The team argues that they delivered value and the goal was too rigid. The Scrum Master is asked to facilitate a discussion.
1. What is the root cause of the conflict, and how should the Scrum Master guide the team and Product Owner to a better understanding of Sprint Goals?
Read the worked answer
The root cause is a misunderstanding of the purpose of a Sprint Goal. A Sprint Goal should provide focus and flexibility, not be a fixed numeric target. The Product Owner treated it as a contract, while the team treated it as a direction. The Scrum Master should facilitate a conversation about the Sprint Goal's role: it is a single objective that gives the team a shared purpose and helps them make decisions when work becomes uncertain. The team's pivot was appropriate because they discovered a better approach. The Scrum Master might ask: 'What did we learn about our users? How did our pivot serve the Sprint Goal's intent?' The discussion should lead to redefining future Sprint Goals as outcomes that are valuable but not necessarily numeric, and ensuring the Product Owner collaborates with the team to craft goals that allow for emergent work. The Scrum Master should also emphasize that the Sprint Review is for inspecting the product and adapting the backlog, not for blaming. The outcome should be a shared agreement on how to set Sprint Goals that balance ambition with flexibility.
2. How should the team and Product Owner use the Sprint Review to inspect and adapt based on this situation?
Read the worked answer
The Sprint Review should focus on inspecting the increment and the Sprint Goal, and adapting the Product Backlog. The team should present what they learned from the pivot: why the original approach failed, what data led to the new solution, and the actual impact (1.5% improvement). The Product Owner should use this information to update the backlog, perhaps by adding items to further investigate conversion improvements. The review should also include a discussion of whether the Sprint Goal was still relevant and how well the team responded to change. The Scrum Master can guide the conversation toward actionable insights: 'What does this tell us about our assumptions? How can we set a Sprint Goal that allows for such discoveries?' The review should not be a blame session but a collaborative effort to improve. The team and Product Owner might agree to set Sprint Goals that are more outcome-oriented and less numeric, or to include a hypothesis-driven approach. The key is to use the review to adapt the plan, not to judge performance.