In Scrum, the three roles Product Owner, Scrum Master, and Team are all important in their own way. In few words: The Product Owner is responsible for the project roadmap, i.e. he has to decide which features from the Product Backlog should be realised next depending on his prioritisation. The most important jobs for the Scrum Master are to keep the Scrum Process running, to protect the Team from impediments (or resolve them), and to act as a moderator. Last, but not least, the Team is responsible for the technical decisions and the accomplishment of the Sprint Goal.
But there is one thing that makes the Product Owner role quite particular for a project: The quality of the Product Backlog Items is crucial for the project progress. When put into the Selected Product Backlog of a Sprint, these items have to be worked on by the Team during the Sprint.
So, what happens if the items are of poor quality? And what do I mean by poor quality?
The description of a Product Backlog Item of poor quality is incomplete, ambiguous, unclear in such a way that the Team is not enabled to satisfy the Product Owner’s idea regarding that item. If such an item is part of the Sprint, it causes – in best case – a lot of unnecessary communication during the Sprint which as a result decreases the Team Speed. But normally, the effect is even worse. If the Team does not hit the Product Owner’s need, the delivered piece of software will not work as desired. Agile Processes often measure the project progress in terms of software features. Using this definition of project progress, there is no or slow progress in case the implemented features do not work as expected by the Product Owner!
To gain high quality Product Backlog Items, these are some basic demands on the Product Owner:
- The Product Owner has to know what he wants.
- Yet more important: He must be able to tell the Team what he wants.
- Most important: The Product Owner must have an urgent need for high quality Product Backlog Items. He must feel the necessity for items of high quality; he must recognise that poor quality items hinder the project progress. So, it is in the Product Owner’s interest to have good items and in some way he should feel responsible for that.
The Product Owner does not need to be left alone with the task of producing high quality Product Backlog Items. The Team can help: It just has to insist on good or exact descriptions. Moreover, the definition of acceptance criteria is crucial. The Team may work with the Product Owner on their respective formulation (at best during Estimation Meetings). The goal of Estimation Meetings is to produce high quality Product Backlog Items. Furthermore, the Team can improve its knowledge of the business domain which in turn leads to Product Backlog Items of better quality. A ubiquitous language is quite helpful here.
So, for short and as a summary, in my eyes the Product Owner role is the most important one in Scrum with respect to the project progress. The Product Owner has to internalise the need for high quality Product Backlog Items. He must not be content with poor quality Items. He must recognise that the latter slow down the project progress. Together with the Team, the Product Owner can produce high quality Product Backlog Items.