What Does A Product Owner Do, Anyway?

A recent question in the scrumdevelopment group captured my imagination.  I had to write a response before sleeping.  Most of this post repeats my message in the group.  I’ve tried to polish it a bit for posterity.

The Questions

The original post in the group asked some hard questions about the role of the Product Owner.  Questions about this role are normal since the original Scrum definition does not go into detail about the day-to-day work of the Product Owner.  I think this is intentional as one definition of this role would not fit very many teams and enterprises.  Let me paraphrase and condense the questions:

How does the Product Owner build and maintain the Product Backlog?  How does he ensure the Sprint Backlog is ready for planning?  And, how much time should be spend doing these things?

Study the Role

To understand the power, nature and key importance of the Product Owner role, we should first understand the big picture.  Some of the best documentation about the Product Owner role comes Roman Pichler. Look around his site for some great information.  In particular, Roman produced a slide set that has helped me many times when explaining the Product Owner role to executives and teams.  Read through this set on being an effective Product Owner [PDF] for some great insight.

The process of gathering information about story content; requirements, UI, etc. can vary significantly from company to company and team to team.   Scrum does not provide direct instruction about how the Product Backlog should be assembled and maintained. Scrum mostly says that the Product Owner is in charge of the backlog.  Lets focus on the main goal for the Product Owner with regard to Sprint Planning:

• The Product Owner needs to have at well defined stories ready at the start of the meeting.
• These need to be in business value priority order.
• There needs to be enough ready to fill at least one Sprint Backlog and maybe a few more, just in case.
• These prepared stories define “What?” is to be created and how everyone will know the creation is complete.

To meet these goals, the Product Owner can use whatever method is needed to collect, document, understand and define the answer to “What?” should be created.  Some things the Product Owner might do:

Product Backlog Grooming

In Roman’s writings he emphasizes the idea of a backlog grooming section. There are others also emphasize this idea and I agree with them. Sometime during the Sprint, the Product Owner and all the team developers will spend time fleshing out the stories for the next sprint and maybe a couple more. This allows the team a forward look to help guide the current work and keeps them on the road. Most importantly, it helps the Product Owner understand the costs, risks and benefit of imminent stories.

Stakeholder Communication

The Product Owner will call meetings with the various stakeholders (Marketing, Production, Finance, etc.) to create and refine stories. The Product Owner represents these interests and people to the developers on the Scrum Team. There needs to be communication with these stakeholders often so that their interests are well represented in the stories and hence the end product. These people are not on the Scrum Team (i.e. they are “chickens”), but they are customers, so their input is vastly important.

Team Communication

Besides a formal grooming session, the Product Owner should be available at any time to talk, discuss and meet with the team or individual developers. The best communication method is face-to-face conversation. When such is done between people that regularly spend time together, misunderstanding is much less likely to happen. Specs, diagrams, drawings, etc. are great. Do them asneeded in order to create a great end product. Documents are not the primary means of communication. Face-to-face is the primary means.

Time to Prepare and Define

The amount of detail and work in all this grooming and communication should be biased toward the present and face-to-face communication.

The detail in the Backlog request as far as features, business rules, and the like, should be only as much as needed for customers, Product Owner and team to understand each other. Once they are used to talking and working together, not very much will be needed. Stories in the next sprint or two will have more of this communicated while those further down the Product Backlog will have less. No reason to spend lots of time defining things that are weeks or months away since they will change.

The Product Backlog does not contain detail design.  They should have as little design information as possible, for the moment’s need. Maximize the work not done.  Remember, the team defines the “How?” of the work, which is the design.

• If the story is in the current sprint, there will be lots of this detail as it is implemented.
• If the story is expected in the next sprint, only as much as needed to be ready for Sprint Planning. Not too much.
• If the story is expected two or more sprints out, only as much as needed to have an understood vocabulary around the story. Not very much at all.

When a Product touches several domains (Marketing, Production, Finance, etc) besides the “product” domain, resist the temptation to do Product Owner by committee.  The Product Owner needs to be the one person that the rest of the Scrum Team asks for decisions of priority and completeness of work. The Product Owner may represent many other functional customers but those customers are not members of the team. This is not to say that developers are not allowed to talk to customers, they should. But questions of story definition and priority are for the Product Owner to determine.

The definition of done is defined by the Product Owner, based on customer input. It is part of the answer to the “What?” question. It should be in the story before the Sprint Planning meeting starts.  During the Sprint Planning meeting the developers may reveal that the story is to big or to difficult or somehow not possible to accomplish as defined. This is only because the “How?” that is answered by the developers cannot meet the definition of done for some reason. Hopefully this does not happen too often and usually should be resolved in the Product Backlog Grooming and communication with the customers.

Definition of done should also include technical requirements such as “Shall pass unit tests” and “Shall be built on the official build computer before demonstration.”  These the developers should define and follow.  The Product Owner should understand the importance of high craftsmanship to the end product.

The Product Owner role should not be taken for granted.  It is a key role that each team and company must refine in their own way.  Keep learning about it all the time.  It is one focus that almost always can be improved.