You’re an experienced Scrum Master beginning a new project. You meet with your Product Owner (PO) for the first time and hear him or her say any or all of the following:
- “I’ve never worked in this role before.”
- “I’ll do my best to be on-site as much as possible.”
- “I’ve completed Certified Scrum Master training, but I’ve never applied it in practice.”
- “I’m the Product Owner for your team, and nine others.”
Your spidey sense is now tingling. You are going to be working with an inexperienced and/or overextended PO. Fear not, however. Here are some methods and remedies you can apply to get your PO up to speed.
Establish a Common Understanding of Team Roles
The first thing an experienced Scrum Master should do when faced with an inexperienced/overextended PO should be to meet with them. Ensure that both parties have a shared understanding of all the roles on the scrum team. Your biggest risks with regards to this area are a PO who attempts to do everyone else’s jobs or a PO who is unaware or inactive in the face of their responsibilities.
While there are multiple resources in print and on the internet that detail the responsibilities of a PO in an “orthodox” Agile Scrum delivery effort, you should define this for your team. In my experience, the PO must at a minimum provide the following:
- End User Representation: The PO must think of themselves as an ambassador representing the typical user or user personae on behalf of whom the team is developing working software. What do these users want? What do they not have right now in terms of functionality, but would wish to have in the future product? If they are completing certain tasks at present in a certain manner, do they want to keep doing it that way in the new system? If the PO cannot answer these types of questions from the scrum team, they must be able to reach out to people within their organization who can.
- Understanding of User Stories: The language of requirements are now user stories that follow, at a minimum, the INVEST model. You, as a Scrum Master, likely have the most work to do in this area to help your new PO. It is crucial for them to understand a basic development lifecycle, what makes a good user story. This ensures that backlogs consist of more than just end user desires.
- Backlog Grooming: Having answered questions about the product strategy and vision in their role as end user ambassador, the PO next must be directly involved in building out Epics, User Stories, and Spikes. How are those end-user needs translated into workable chunks for the scrum team? How are technical needs represented on a backlog? Is there any type of work for a project that should not be on a backlog?
- Work Prioritization: With an initial backlog in-place, the PO must provide ongoing guidance to the scrum team on priorities. If everything in the backlog is an urgent priority, then nothing is. For the PO, prioritization is a continuous exercise of asking, in the guise of the end user, if I could only have one piece of functionality represented by a story in my backlog, which one would it be? If I could have two, which two? And so on. Prioritize each story with regards to all the other stories in the same backlog.
- External Reporting: The PO should be the face of the scrum team to outside stakeholders, including but not limited to their superiors. This area is the most likely to cause the inexperienced PO the most stress. Confronted with new terms specific to Agile Scrum methodology (e.g., story points, velocity, burndown chart, etc.), the PO may have the instinct to defer reporting to the Scrum Master. This is a mistake to be avoided—the “O” in PO stands for “Owner”. The PO must master the reporting aspect of agile scrum in order to have credibility within the organization.
The PO’s Responsibilities are Collaborative
Okay, you’ve met with your new PO and established responsibilities. They’ve gone from a state of mild anxiety, to full-fledged freak out—I have to do all of that by myself? Talk them off of the ledge and let them know that you, and the rest of the team, will collaborate to:
- Create Epics: The Scrum Master does not expect the PO to arrive at the first, second, third, or nth meeting with a set of fully-fleshed out epics. However, the PO needs to articulate, in business rather than technical terms, just what it is, at a high-level, what the software is capable of. In general, what things do users want/need from the new system? These high-level needs and wants can translate into epics.
- Decompose Epics to User Stories: Okay, time to get more granular and start writing some user stories. The Scrum Master and/or the analyst must take the lead and ask probing questions about the epics. It is important do so in language the PO can understand. When you say users must be able to retrieve and view usage data—which data in particular? Which fields should be displayed to them? What are they using the data for, and at which points in the overall process? Again, stress to your PO that they need not know all the answers. They only should be able to find the answers from the appropriate parties in a timely manner so that epics can be decomposed into user stories.
- Document Acceptance Criteria: We’ve made some user stories. The inexperienced PO will likely not be able give you Acceptance Criteria for them. The PO should, however, be able to answer the following question—if the functionality delivered by this user story does the following things, would you consider that story done? The Scrum Master (or analyst) should turn those “following things” into Acceptance Criteria for the story and review them again with the PO. Owning the product includes owning the right to accept or reject the work.
- Craft Requirements Questions to the Users/Customers: End users/customers for the most part neither know nor care about your team’s architecture, technical stack, automated test process, etc. They only care about how the software currently works or will work in the future. Help the PO understand the issue at-hand in business terms (i.e., it’s impact on the end user/customer). They can then ask the right question to the right people.
- Calculate and Apply Team Velocity for External Reporting: As stated above, the PO is responsible for external reporting. The most common questions from management to a scrum team are, how much can you deliver, and by which dates? An experienced Scrum Master must provide his PO with the tools to answer this question. Soothe their anxiety around reporting by constantly calculating team velocity. Then apply it to your team’s well-groomed backlog such that the PO can give a reasonable response to management’s question.
Stress That Sometimes Attendance is a Requirement
Insist that the PO be physically present at the following Agile ceremonies:
- Planning Sessions for sprints and increments
- Sprint Reviews
- Sprint Retrospectives
Per Woody Allen, 80% of success is showing up. For the inexperienced PO, the figure is probably closer to 90%. As a Scrum Master, do as much as possible to ensure your PO shows up to these ceremonies. They may not initially understand much of what’s taking place, but skipping the meetings altogether will not improve their understanding.
Act as a Coach and a Servant-Leader for the PO
Above all, help the new PO to understand that they need not know everything right now. In waterfall/SDLC, all requirements must be known before development starts. Agile Scrum is deliberately different. In Agile, we are expected to build a release candidate every sprint. The candidate will not be perfect. We will change it based upon user feedback. The closer we are to having to deliver a user story, the more detail the team must have. Help the PO to focus on what’s in front of them.
Just as you became a better Scrum Master through experience with the support of your team, so too shall you help your inexperienced PO become a master of their craft.
If you would like more suggestions, feel free to leave a comment or to reach out.
[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]