The Sprint Goal Nobody Can State
A five-person Scrum Team has been running Sprints for six months. When the Scrum Master asks each member to state the current Sprint Goal, four give different answers and one says "finish the backlog items we picked." The Sprint Backlog is a flat list of 22 items carried over from the Product Backlog, ordered by the Product Owner. Mid-Sprint, the Product Owner adds four urgent items and the Developers drop two original items to compensate. There is no shared understanding of what the Sprint is trying to achieve beyond "get through the list." Velocity has been flat, but the team reports feeling busy and unfocused.
1. Diagnose the root problem and explain why the flat list of 22 items is a symptom rather than the cause.
Read the worked answer
The root problem is the absence of a Sprint Goal - a single objective for the Sprint that gives the team a shared target and a rationale for the Sprint Backlog.
Without a Sprint Goal:
- The Sprint Backlog becomes a list of unrelated items, so "done" is ambiguous and focus fragments.
- The Developers have no basis for negotiating scope with the Product Owner mid-Sprint, because nothing defines what is essential versus negotiable.
- The team cannot explain why the Sprint matters, which is exactly what the four different answers reveal.
The 22-item list is a symptom: it is what a backlog looks like when no one has articulated an objective. Shortening the list without a Sprint Goal would not fix the underlying lack of focus.
2. The Product Owner adds four urgent items mid-Sprint. How should the team evaluate whether this is acceptable?
Read the worked answer
Scope may be renegotiated between the Product Owner and the Developers as long as the Sprint Goal is not endangered. The test is not "can we fit more work" but "does this change keep us on track for the Sprint Goal?"
A sound response: the Developers assess the new items against the Sprint Goal and their forecast, and discuss with the Product Owner. If the new items are consistent with the goal, they may swap lower-value work out. If the new items conflict with the goal, the Product Owner must choose between preserving the goal and abandoning it - and abandoning the Sprint Goal mid-Sprint is a serious decision, not a routine swap.
What is not acceptable is silently dropping two items to absorb four without anyone checking the effect on the goal. That is how the team ended up unfocused.
3. How should the team construct a Sprint Goal going forward?
Read the worked answer
The Sprint Goal should be crafted collaboratively during Sprint Planning by the whole Scrum Team, emerging from the Product Owner's proposed objective and the Developers' technical judgement. It should express a coherent outcome or value, not a list of tickets.
Practical guidance:
- The Product Owner brings a candidate objective tied to product value; the Developers assess feasibility and refine it.
- The goal should be specific enough that the team can say whether the Sprint succeeded, but flexible enough to allow scope negotiation.
- The Sprint Backlog is then built to serve the goal, so items can be added or removed without losing the thread.
A goal the whole team can state in one sentence is the practical test.