When Scrum Teams experience a work quality issue, they sometimes shift the responsibility for quality control to the Product Owner as a solution. Not only is this impractical, but it's also anti-Scrum. Here's why.
Defining our Terms
Before we delve into why having the Product Owner mark PBIs as “closed” is not a good idea, let’s define the two Scrum accountabilities at play and the Definition of Done.
The Product Owner is accountable for maximizing the product's value resulting from the Scrum Team’s work. One tool they use to achieve this is the Product Backlog, commonly defined as the team’s “to-do” list. Each to-do is referred to as a Product Backlog item. The Product Owner is accountable for the Product Backlog’s content and item order.
Developers are those who do the product work on the team. Whether the product is software, human resources activities or any other good or service, Scrum refers to the people who do the work as Developers. So whether the folks doing the work are software coders, testers, human resources specialists or marketers, Scrum calls them “Developers.” They are accountable for turning PBIs into an increment of Product that meets the team’s Definition of Done every Sprint.
The Definition of Done describes all the work the team needs to do for each PBI before they consider it completed. A Definition of Done might require that every PBI be tested or inspected in a code review process, for example. If the organization has not created a Definition of Done, then the Scrum team creates one. All Scrum Teams working together on a single product (commonly called a product team) must share a Definition of Done.
Why the Product Owner closing the PBI is impractical
Consider the case of a single Product Owner working with several Scrum Teams. Asking that person to close PBIs on behalf of all of those teams is impractical. Imagine a product team including five or more Scrum Teams rolling up to a single Product Owner. Imagine that team has sixty (or more) Developers. Think of a single Product Owner responsible for checking the work of every Developer and closing PBIs once completed. What a nightmare!
Even for smaller teams, it’s inefficient to ask the Product Owner to check the work of every Developer. Given that the Developers must verify that each PBI meets the Definition of Done before it can be closed, it’s cumbersome to contact the Product Owner to take the administrative step of closing each PBI once completed.
How would the Product Owner know that the work is complete?
They would have to ask the Developers.
Each time a Developer completed a PBI, they would need to contact the Product Owner for verification, thus creating an unnecessary bottleneck and feeling like micromanagement after a while.
Why the Product Owner closing the PBI is anti-Scrum
The Developers are in the best position to determine when a PBI meets the Definition of Done and are accountable for delivering those PBIs. Having the Product Owner verify each PBI is asking them to take on someone else’s work. Such action falls outside the Scrum framework and distracts the Product Owner from their core accountability to maximize product value by populating and ordering the Product Backlog.
In addition, by having the Developers close PBIs when they are complete, they take ownership of their work and demonstrate their commitment to delivering a high-quality product that meets the Definition of Done. Taking this accountability away from them is disempowering.
Here’s what to do instead
A Scrum Team struggling with low work quality should discuss it in the Sprint Retrospective, asking specific questions:
Does the team have high technical debt?
Does the code need to be better organized?
When individual team members are overwhelmed, do others help out?
Are there PBIs the Product Owner could add to the Product Backlog that would improve quality?
Other options include the team updating their Definition of Done to increase standards around testing, security or code reviews or other work they think might improve the quality of the product resulting from the team's work.
Conclusion
Scrum Teams looking to address their low-quality work will sometimes ask the Product Owner to "review and close" PBIs as a means of quality control. Trying to solve low quality this way creates inefficiency, doesn't always uncover the source of the issues, and goes against the Scrum framework and its accountabilities. The Developers are best positioned to determine if their work meets the Definition of Done. If what they produce is missing the mark, discussing the issues at the Sprint Retrospective is best for uncovering a more efficient, accountable, and collaborative approach to resolving the problems.
Rebel Scrum, based in Madison, Wisconsin, is a Scrum.org training partner and a leading provider of private Scrum training for organizations. Our primary focus is on delivering high-quality group Scrum training to organizations seeking to enhance their Agile practices. At Rebel Scrum, we are committed to contributing to the success of our clients by providing tailored training solutions that cater to their specific requirements. We understand that each team is unique, which is why we offer customized group Scrum training sessions designed to meet your organization's distinct needs. To initiate a discussion about how we can support your team's Agile journey and facilitate positive outcomes, feel free to reach out to us at 414-482-5562 or contact us. Let's embark on this transformative journey together!
Comments