The role of the product owner in Scrum is probably the one that is cursed with the most misunderstandings. Personally, I curse the updates of the Scrum guide – the official guide to Scrum – and people’s lack of following-up with these changes for the variety of opinions about different pieces of Scrum around. This blog entry will deal with the role of the product owner.

Chicken or pig?

In the Scrum history, early on, there was a metaphor around a classical joke around that tried to explain different roles. The joke goes something like this (I’m a terrible joke teller):

A chicken meets a pig, and says: “Hey, we should open a restaurant together.” The pig answers: “Hmmm, interesting idea. What would we serve?” “Eggs and bacon.” “Hmmm, I don’t think this is a good idea. I would be committed while you would be involved.”

The bottom line was that some roles in Scrum were committed up to working overtime to deliver the sprint results, while others were only involved. Personally, I think it’s a good thing that Ken Schwaber and Jeff Sutherland banned this metaphor in 2011.

With the understanding of history behind it, early on, people were wondering whether the product owner is committed, or only involved – a pig or rather a chicken? I even think there are different ways to fill the product owner role that would be more chicken-like or more pig-like. My colleague Stefan Roock blogged about three different ways to fill the product owner role, and one that does not justify the name.

But consider the chicken and pig metaphor again. Personally, I think one of the reasons it was dropped, is because it leads to a dysfunction. Most of us won’t like to work overtime. Most of us won’t like to work overtime when that overtime has been put on us from the outside. Historically, the discussions about whether the product owner is a pig or a chicken probably has more to do with “do I have to work overtime when the team works overtime?” The chicken and pig metaphor provided an excuse for that answer, and I can only imagine the amount of discussions around this topic rather than getting the work done.

In the end, the product owner cannot deliver business value to the customer without the development team. The development team cannot deliver business value to the customer without the product owner. These two roles form a a symbiotic relationship, and in most implementations you are better off by working closely with the product owner rather than leaving her out. The product owner on the other hand should not leave the development team alone for the duration of a sprint. The product owner should provide feedback to the development even during the sprint. The product owner does not order product increments at the development team. It’s in the best of her interest, too, to support the development team to deliver the highest business value at the end of the sprint. I have not seen an implementation where this did not involve collaborating with the development team. Today’s literature has incorporated the term of the Scrum team. The Scrum team includes the product owner, the ScrumMaster, and the development team, and ties them together; it makes clear that we are sitting in the same boat (and it’s not a galley).

The Product Owner accepts stories during Sprint Review

I think this also is a side-effect of the chicken-pig metaphor. Some teams interpreted the role of the product owner as someone who is ordering a product increment during Sprint Planning at the development team. The motivation behind that probably has to do with busy product owners who don’t have enough time to pay attention to what the development team is building.

Of course, this kind of implementation – especially for teams and organizations new to Scrum – is more likely to end in unpleasant surprises like half of the stories being not accepted during the Sprint Review meeting. Consider the following scenario: The development team demonstrates the stuff that it has been working on during the Sprint in front of stakeholders, and the product owner. For half of the things shown, the product owner says that she does not accept it. If I were a team member on that development team, I would feel ashamed, and probably would refuse to attend any other Sprint Review meeting in the future. That does not appear a helpful situation to me.

The foremost objective of the Sprint Review meeting lies in receiving feedback about the product increment. That means that we should invite people from outside the Scrum team to provide us such an outside perspective. We usually call them stakeholders. Since they were not involved with our product for some time – in most cases at the least the current Sprint – we need to show them the product, and especially the stuff that we added in the past two weeks. Then we should collect feedback regarding the product from these stakeholders. Oh, and please, stop justifying your decisions when you collect feedback, otherwise you might find out that your stakeholders will not come back. (Development team members, and product owners should remember this.)

The Product Owner should not be invited to the retrospective

I think this was the most widespread rumor at a recent client. It probably has something to do with product owners having too many meetings already to attend yet-another-one. Especially the retrospective appears to be loaded with meta-discussions about how we work, how we feel. I can understand that dropping such a meeting for the product owner is trying to solve the overloaded-by-meetings situation of the product owner.

Now, consider this scenario: we just finished the eighth Sprint. The development team is disappointed because the product owner does not provide timely feedback during the Sprint on the stuff that the team built. They planned 8 product backlog items, and delivered only 2. Everyone is depressed. Now, the development team sits together in a meeting in order to discuss what to improve – oh, and by the way, the product owner will attend that important client meeting while they are doing that. A good retrospective facilitator will manage to reach an experiment like “arrange an all-hands meeting with the product owner to talk about this.” In most cases, though, the retrospective will end with a catalogue of things the development team wants the product owner to change – without talking to her. I think this is unhelpful.

As I mentioned earlier, neither the development team, nor the product owner can deliver high business value on their own solely. They need each other, and they especially need the feedback from each other. That includes the meetings in which we inspect and adapt our work products, and the meetings in which we inspect and adapt our working process. So, the product owner should be included in the Sprint Retrospective by default. Oh, and trust your ScrumMaster to manage to facilitate the meeting in a way so that we can talk about everything, including addressing trust issues that keep us from there.

That does not mean that there won’t be any retrospective meetings that are pointless for the product owner to attend. For example, when the technical infrastructure of the product has so worn out the team in the last Sprint that they need to talk about technical experiments for the upcoming Sprint. That might be boring for most product owners, and I consider it to be ok if she left then. But this should be an exception rather than a rule.

The bottom line is this: As a product owner you rely much more on your development team, and they surely depend on you. Try to collaborate with them more for the better your product might improve beyond what was possible in the past.