20 Questions from New Scrum Master to Product Owner
TL; DR: 20 Questions to Ask the Product Owner to Get up to Speed as a New Scrum Master
From Scrum Master to Product Owner, this set of questions addresses the future collaboration between the two individuals and the rest of the Scrum Team. The questions have been modeled after some basic principles, that high performing teams have in common. Download a printable template for your convenience.
Do you want to get this article in your inbox? Then sign up for the Food for Agile Thought newsletter and join 27k other subscribers.
The Essential Role of the Product Owner for the Success of the Scrum Team
It does not matter if you apply Scrum to the right problem field—emergent products in the complex domain—, or if your Development Teams excels at technical proficiency and delivers Product Increments with the regularity of Swiss clockwork. If your Scrum Team is moving in the wrong direction because the Product Backlog is not maximizing the value customers derive from the Development Team’s work, no one will care—garbage in, garbage out. (You can read more on this notion in Marty Cagan’s post Product Success.)
The individuals who are responsible for maintaining an actionable Product Backlog that delivers value are the Product Owners: “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” (Source.)
The primary way of achieving this goal as a PO is the management of the Product Backlog. According to the Scrum Guide, this activity comprises:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing 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.
Source: Scrum Guide 2017.
As Scrum Masters, we better make sure to support our Product Owners the best we can to serve our Scrum Team to become successful.
The Questionnaire: From New Scrum Master to Product Owner
This set of questions is intended for the first talk between the Product Owner and a new Scrum Master without involving the whole Scrum team:
- What is the product vision and the corresponding go-to-market strategy?
The Product Owner should be the #1 person to go-to for the team if any vision or strategy questions come up.
- How do you learn about new ideas and requirements?
Here, the Product Owner should explain the whole product discovery process. From idea to hypotheses, to experiment, and finally validation.
- How do you include user research in the product discovery process?
I don’t believe, that a learning organization can manage without running user tests continuously. Therefore, the Product Owner should explain not just the whole user testing process, but also how the Scrum Team is involved in product discovery.
- How much time do you allocate on user research and understanding your customers’ needs?
As a rule of thumb, 50 % would be excellent. If it’s less than 10 %, the product discovery process has (a lot of) room for improvement. Follow up with a question on the PO’s workload and how you can support the Product Owner to free more time for talking to customers.
- At what stage do you involve the Scrum Team in the product discovery process?
It is highly recommended to involve the Scrum Team as early as possible in the product discovery process. The sooner the Development Team members participate in the process, the lesser the chances are that solutions are pursued that are technically not viable or would not result in a return on investment.
- How do you organize the collaboration with stakeholders?
This should be an easy question to answer for the Product Owner. There are various ways to establish and improve this communication over time. For example, institute regular meetings with each stakeholder. Or have stakeholders name product ambassadors who act as “liaison officers” and train them. Arrange workshops with stakeholders/ambassadors. Team up with the user experience people and run, for example, user journey or user story mapping workshops. Or invite stakeholders to refinement sessions to explain the value of a user story. Learn more: 11 Proven Stakeholder Communication Tactics.
- How do you deal with pet projects?
You want to know, that your Product Owner can really guard the Product Backlog. Has the individual said “no” in the past? And if the Scrum Teams works or worked on pet projects, why is that so?
- What is your approach to creating product roadmaps?
Roadmap planning—as portfolio planning—is a continuous exercise. The Product Owner should be able to detail the process of the organization.
- How large is your Product Backlog?
I do not believe in the usefulness Product Backlogs, that are larger than what the Scrum Team can possibly handle in three, maybe four sprints. If the Product Backlog exceeds this threshold, the Product Owner might need support to prevent this potentially disadvantageous cluttering of the Product Backlog. After all, we are looking for valuable signals in the Product Backlog.
- What is the typical age of a work item in the Product Backlog?
I doubt the value of a work item, that is already five months old. A “but I have been working on it since” is an excuse in my eyes. (Pro tip: Product Backlog forensics delivers a lot of insight in how the organization works: number Product Backlog items, age of items, who created the items, who commented on the items, who changed the items—there is a lot of helpful information buried in the data.)
- What is your average lead time from picking an idea for validation to adding the corresponding work item to the Product Backlog?
This is actually one of a few metrics, that can provide some insight on how “agile” product discovery actually is.
- Does your Product Backlog contain work items none of the current team members is familiar with?
If so, those should be re-visited with the current team members to ensure a) the work items would still provide value today, and b) there is a shared understanding among all team members regarding the nature of the item.
- How often are you refining the Product Backlog?
That should be a continuous exercise. In my experience, it has proven to be useful to have at least one regular refinement event where the whole Scrum Team participates.
- On how many work items are you working in parallel during Product Backlog refinement?
In my experience, a Product Owner should not make the teamwork on more Product Backlog items than it can handle within the next one to two Sprints. Otherwise, the risk of allocating resources on work items, that may never make into a Sprint Backlog, becomes too high.
- How long does the refinement of a typical work item take?
The refinement should not extend throughout one to two Sprints; context switching perils and work-in-progress limits apply to refinement sessions as well.
- How are you creating work items?
Is it a joint team effort or is the Product Owner writing the user stories and the team estimates them? There is a tendency to observe that Product Owners become more a kind “technical writer” of work items which then get estimated by the Development Team. I strongly suggest, however, to turn work item creation into a joint effort of the whole team to create a shared understanding. Learn more: Essential XP: Card, Conversation, Confirmation.
- How are you discussing work items? Only during refinement sessions, or also on Slack or via comments on tickets, for example?
Every team has its habits and maybe commenting in Confluence, Jira, Github, or utilizing Slack is an effective means of communication in your organization. As long as this happens before the Development Team selects a work item for a Sprint backlog, this should be fine if the Product Owner agrees, too. Discussing its essentials during the Sprint for the first time might be a problem, though.
- Are you changing work items once they become a part of a Sprint Backlog? And if so, under what circumstances?
Well, making them smaller, if the team runs into a problem, is certainly not great, but acceptable—if the work item then still delivers value. Making it larger after the Sprint Planning is, however, not acceptable. It is the prerogative of the Development Team to control the composition of the Sprint Backlog.
- When do you accept work items?
The Scrum Guide mentions “acceptance” by the Product Owner only once in the paragraph about canceling a Sprint: “If part of the work is potentially releasable, the Product Owner typically accepts it.” However, it has proven useful to have a chat between the Product Owner and the team/the engineer when they consider the work item “done.”
- Have you ever rejected work items?
If that is the case, you really like to learn why that happened, and what measures were taken to prevent that from happening again.
The interview script helps an initial conversation between the Product Owner and the new Scrum master to get the latter up to speed. The questions focus on winning traits of high performing, value-creating teams. They range from product vision and strategy, via product discovery, and collaboration within the team, to good practices of product delivery.
What suitable questions are I missing? Please, let me know so that the list can be extended.
✋ Do Not Miss Out: Join the 8,000-plus Strong ‘Hands-on Agile’ Slack Team and Learn more about Agile Metrics
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.