When I coach companies on Scrum and Agile Methodologies, I’m used to having dedicated, co-located Product Owners and teams. Lately it seems, especially with large corporations involved in an Agile transition, Product Owners and Scrum Masters are leading multiple project teams; often they are not co-located. It can be challenging when trying to coach teams on Agile Manifesto values, such as: Individuals and Interactions over Processes and Tools. Often during these transitions, companies expect a PO to be a part-time Product Owner: doing PO work in addition to his/her day (or real) job. Many times I have had Product Owners ask me to help justify their full-time involvement so that their supervisors understand the extent of the time commitment involved with the role. I have done this by describing what a typical Product Owner does each day. So in this post, I am going to jot down a (by no means exhaustive) list of what a Product Owner does on a daily basis (in no specific order):
- Attends the team’s daily planning meeting (aka standup) to understand the team’s progress and issues towards the sprint goals.
- Captures customer requirements (and wish lists) by writing (or helping others write) User Stories.
- Accepts/rejects completed User Stories.
- Prioritize and update the backlog.
- Is available to the team each day to answer questions and clarify stories.
- Verifies that stories are in the proper format, contain valid confirmation (aka Acceptance Criteria), and are in-line with the product vision and scope. This includes any necessary design details, business rules, etc.
-
Makes sure that project/product vision and goals are clearly defined and communicated to everyone.
-
Works with the team to ensure stories meet the agreed upon “Definition of Ready” before pulling them into the sprints.
-
Helps remove obstacles that the team and Scrum Master cannot remove.
-
Makes sure that the Scrum Team has a direct connection with end users through story development and the Sprint Review.
-
Keeps stakeholders informed on project status and how much value has been generated for money spent.
In addition to that, on a bi-weekly or as needed basis:
- Participate in the demo and retrospective meetings.
- Work with the team to groom the Release backlog.
- Work with the team to plan the iterations.
- Meets with customers and stakeholders on a regular basis to field questions and inform them of project/product updates and changes.
- Conducts the Sprint demo with the team to present the incremental functionality to users and stakeholders.
Feel free (or compelled) to add your own. My thanks to Bob Schatz @Agileinfusion for his sage advice and input.
Agile Business Connect 
Although your lists are, in my view, largely correct, like all lists, they are “items to check off.” In other words, dance steps to follow. You complaint is of the PO being part time. Someone’s not hearing the “Agile” music.
I’ll give you two answers, the philosophy, and how to effect the practice.
Philosophy: One of the most prevalent reasons projects fail is the misalignment of product/service behavior and customer expectations. (Check out – http://www.marketingvp.com/guests/globe/oven.htm and also http://www.marketingvp.com/invest/evidence.htm) When PO’s don’t have a clear direction, it’s time to be scarce.
Technologist can be to blame too. When there is NOT a clear separation of business behavior from design, the technologist rule the conversation through the stories. Keep design out of those stories! No GUI, Databases, Screens, blink-ee lights. Salable behavior only. (See http://softslide.us/coupler/jusThinkingPA.htm). Do not have developers asking permission on their technical solution, until it’s demonstrated.
So how to “encourage” your PO to participate? It’s simple, after all, Agile is “High Trust.” Trust what the PO is telling you with their actions. Recognize that it may be the PO or the organization elevating other demands. Either way, all you do is be considerate of their time elsewhere, make reasonable business decisions on their behalf when they are not present, and send them a brief write-up of the decision the team made in their absence. CC as needed.
And, oh… put an extra cup of coffee on, I think you may have a more frequent guest. 😉
Rod
Rod:
I agree with everything you have said. Here’s the main issue with large Agile Transitions: The business folks, who are the Product Owners for IT, were hired for a specific job prior to the transition to Agile. During the transition, they are still expected to do the job they were hired for, PLUS the PO job. In my experience with large companies, this is par for the course. Yes, I have had many conversations with executives about GIGO, and still they are willing to accept the risks and opportunity costs created by part-time POs. More frequent guests are always welcome. The next post should be up soon!
Forgive me for responding before more frequent guests.
That Microwave oven was one of many family inventions. It was one that failed for 30 years due to lack of business involvement.
GIGO – We know of it, we have labeled it; does it follow that we must accept the “Garbage Out” from the “Garbage in”?
When did corporate austerity trump market acceptance? The customers are who count. And that’s not a slogan.
I look forward to hearing from others.
Kind regards,
Rod