Scrum Rules: Your Product Owner Never Interrupts the Team Mid-Sprint With New Items

The Product Owner is involved with the other Team Members throughout the Sprint, but after the Sprint Planning meeting is completed, the Product Owner cannot add to the scope of the work being done during the Sprint.

New Product Backlog Items, no matter how high their priority, must be put onto the Product Backlog for the team to look at in the next Sprint. This restriction is meant to allow the team to truly be focused and committed to the work of the Sprint and to allow them to make commitments and learn to keep them, thereby building trust. The Product Owner can, of course, collaborate on the details of the PBIs the team has chosen for the Sprint. If the Product Owner does indeed force a team to take on extra work during the Sprint, it breaks the focus of the team and can lead to the team’s failure to complete the work they planned during Sprint Planning which, if repeated often enough, can destroy trust in the team.

Interruptions are one of the most pernicious forms of dysfunction and need to be dealt with quickly and permanently. The Scrum Master is responsible for this and can use three techniques to assist the Product Owner and the team.

1. Shorten the length of the Sprint – sometimes dramatically – to give the Product Owner assurance that high-priority Product Backlog Items will, indeed, be handled by the team quickly. In one organization, the team had to go from 2-week long Sprints down to 2-day long Sprints in order to keep up with the frequency of high-priority requests and still keep to their commitment during a Sprint by deferring the requests to the next Sprint.
2. During the Sprint Retrospective, ask the team, with the Product Owner present, about the impact of the interruptions. Like with all retrospective environments, the Scrum Master must facilitate the creation of an environment that is safe for participants to discuss challenging topics. The purpose of this facilitation is to make sure that the Product Owner knows from the mouths of the team members themselves what kind of negative impact the interruptions are having. Common complaints raised here include feelings of guilt for not finishing planned work, unsustainable overtime to do everything, or demoralization due to criticism from stakeholders not getting the work that was planned for the Sprint.
3. For each interruption, do a root-cause analysis to discover why this requested work was not known about earlier, or how similar kinds of requests could be avoided in the future. This works particularly well for interruptions due to quality problems, but may also expose dysfunctional organizational processes, technology instability, or skill gaps on the team itself. There are numerous root cause analysis techniques to consider.

During the Sprint: No changes are made that would endanger the Sprint Goal; — The Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…