Shades of Scrum: 3 Product Owners and a Product Owner Shaped Object
The Scrum Guide by Ken Schwaber and Jeff Sutherland states about the Product Owner role:
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Ensuring the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
Product Owner Personas
I have seen four different types of Product Owners. I have created little personas to describe them: Walter, Marty, Eric and Jeff.
Walter is very accurate when preparing the next Sprint. He knows the domain very well and doesn’t need the support of the team for Sprint preparation. He only calls the developers for Sprint preparation when he needs an estimate for a newly created Product Backlog Item. In the Sprint Planning Walter hands over very clear and detailed specifications of what has to be done in the Sprint.
Walters Product Backlog Items are described very carefully and have a detailed list of acceptance criteria. Therefore there is no need for intense contact with the development team during the Sprint.
Marty asks the development team regularly for help during Sprint preparation. He writes some of the Product Backlog Items together with the development team and often details Product Backlog Items and their acceptance criteria together with the team.
Marty is available during the Sprint to clarify details that are not described by the Product Backlog Items.
Eric does not only work as a Product Owner; he is also a member of the development team. He creates and manages the whole Product Backlog together with the development team. When the Sprints begins, the Product Backlog Items are often very rough and a lot of stuff is detailed and clarified during the Sprint.
Jeff has some distance to the development team. Normally he interacts with the development team only during Sprint Planning and Review. His Product Backlog Items are coarse grained leaving out most of the details. The development team has to figure out the details itself. Jeff may provide a Product Backlog Item “Birthday list” and the team has to figure out the filter criteria, printed data and layout.
In my point of view three of the described Product Owner personas are valid Scrum Product Owners and one is only a Product Owner Shaped Object (POSO). From an outside view the POSO complies with the Scrum rules but he doesn’t incorporate the Scrum mindset.
Walter is the POSO and his complete name is Walter Falls. His way of working is still sequential waterfall. He specifies the requirements and the team does the execution. What is missing here is the overlap of development activities (namely analysis and development) and the collaboration between the Product Owner and the development team.
Walter is a guy you would meet in a lot of Scrum implementations, because his way of working is very similar to the way the people have worked in waterfall projects for years. When doing a transition to Scrum Walter may be a suitable temporary type of Product Owner. But you should keep in mind that it is only an intermediate step and that Walter should transform into one of the other Product Owner personas.
Marty is the Product Owner that is described by the most of the Scrum literature and he is the most common valid Scrum Product Owner. I have chosen the name ‘Marty’ since I think this type of Product Owner is what Marty Cagans book “Inspired” implies.
Marty is relatively easy to implement and is therefore quite often. For a team beginning with Scrum Marty is normally a good choice. And then it may evolve into Eric or Jeff.
A lot of people think that Eric and Jeff aren’t valid Scrum Product Owners since they don’t provide all the details to the development team. Often the following statement referring to the dotted lists with the Product Owners responsibilities from the Scrum Guide is ignored:
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
As long as Eric (or Jeff) remain accountable their approach to the Product Owner role is completely valid.
Eric is the most collaborative Product Owner regarding the interaction with the development team. Eric is a good choice when the what (the Product Backlog Items) is very unclear and need to be refined and redefined within the Sprint based on feedback gained during the Sprint. Teams doing Lean Startup with Scrum normally end up with Eric as the Product Owner. (And that is the explanation for the name. The cross-functional Lean Startup team described by Eric Ries is very similar to a Scrum team with Eric as the Product Owner).
Jeff is the less supportive Product Owner but gives the development team the greatest freedom. The development team is not only responsible for the how but also defines large parts of the what. Jeff needs a mature development team with deep domain knowledge. Typically a Jeff Product Owner comes with long Sprints (e.g. a month) because the development team needs more time within the Sprint to figure out the details of the Product Backlog Items.
Jeff is suitable when the Product Owner can’t dedicate a lot of time to the Product Owner role. An example could be a CEO or other manager who assumes the Product Owner role. But this is only successful, when the development team has enough domain knowledge and is trusted adding all the details of the Product Backlog Items in a meaningful way.
And for the name: As far as I understand the first Scrum software project done by Jeff Sutherland at Easel incorporated a Jeff as Product Owner.