A Scrum Team has just finished Sprint Planning. They have a clear Sprint Goal and a well-defined Sprint Backlog. A few days into the Sprint, a critical security vulnerability is discovered in a previously released Increment, requiring immediate attention. The Product Owner determines this vulnerability must be addressed within the current Sprint. What is the MOST appropriate way for the Scrum Team to handle this situation?
- AThe Developers should pull the security fix into the Sprint Backlog and collaboratively re-negotiate the Sprint Scope with the Product Owner to maintain the Sprint Goal.
- BThe Scrum Master should cancel the current Sprint and initiate a new Sprint Planning for the next Sprint.
- CThe team should defer the security fix to the next Sprint to avoid disrupting the current Sprint's plan.
- DThe Product Owner should add the security fix to the Sprint Backlog, and the Developers must absorb the new work.
Show answer & explanationAnswer & explanation
Correct answer: A. The Developers should pull the security fix into the Sprint Backlog and collaboratively re-negotiate the Sprint Scope with the Product Owner to maintain the Sprint Goal.
When unexpected critical work arises mid-Sprint, the Developers, who own the Sprint Backlog, should collaboratively work with the Product Owner. They need to assess the impact, and if necessary, re-negotiate the Sprint Scope to ensure the Sprint Goal remains achievable, or if not, discuss options like Sprint cancellation (a last resort).
Why the other options are wrong
- B. Cancelling a Sprint is a severe action, typically only taken if the Sprint Goal becomes obsolete. Re-negotiation should be attempted first.
- C. Deferring a critical security vulnerability is generally unacceptable due to potential severe consequences and goes against the principle of addressing the most valuable/urgent work.
- D. The Product Owner does not dictate the Sprint Backlog; the Developers manage it. Absorbing work without negotiation risks the Sprint Goal.
Adapting Sprint Backlog Mid-Sprint
The Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint. Developers can adjust the Sprint Backlog throughout the Sprint, and may re-negotiate the scope with the Product Owner if new work emerges.
- Sprint Backlog is managed by Developers.
- Scope can be re-negotiated with Product Owner.
- Sprint Goal should remain the focus.
Memory trick: Urgency Requires Team Collaboration and Adaptation.