20 Questions from New Scrum Master to Product Owner

TL;DR: 20 Questions from New Scrum Master to Product Owner

From Scrum master to product owner, this set of questions addresses the future collaboration between the both and the rest of the team. The questions have been modeled after some basic principles, that high performing teams have in common. (You can read more on this topic in Marty Cagan’s post Product Success.)

20 Questions to Ask the Product Owner to Get up to Speed as a New Scrum Master

This post is following up on the previous post 20 Questions a New Scrum Master Should Ask Her Team to Get up to Speed.

This set of questions is intended for a first talk between product owner and Scrum master without involving the whole Scrum team.

Download a Printable Template of “20 Questions from New Scrum Master to Product Owner” Questionnaire

You can download the questions as a PDF (without the comments), print and use them for yourself. If you do so, I would appreciate your feedback on how this worked out for you, and what questions you would add to the list. (Please note, that downloading the PDF will also subscribe you to our weekly, hand-curated newsletter, if you haven’t yet signed up already. You can unsubscribe at any time.)

1. 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 questions concerning vision, or strategy come up.

2. 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.

3. 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 that.

4. How much time do you allocate on user research and understanding your customers’ needs?

   50 % would be great. If it’s less than 10 %, the product discovery process has (a lot of) room for improvement.

5. 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 engineers 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.

6. 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 grooming sessions to explain the value of a user story.

7. How do you deal with pet projects?

   You want to know, that your product owner can really guard the product backlog. Has she said “no” in the past?

8. 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.

9. How large is your product backlog?

   I do not believe in product backlogs, that are larger than what the team can handle in three, maybe four sprints. If the product backlog exceeds this threshold, the product owner might be in need for some support.

10. What is the typical age of a user story in the product backlog?

    I doubt the value of a user story, that is already five months old. A “but I have been working on it since” is an excuse in my eyes.

11. What is your average lead time from picking an idea for validation to adding the corresponding user story to the product backlog?

    This is actually one of a few metrics, that can provide some insight on how “agile” product discovery actually is.

12. Does your product backlog contain user stories none of the current team members is familiar with?

    If so, those should be re-visited with the current team members to make sure a) the user stories would still provide value today and b) the estimation is still accurate.

13. How often are you grooming the product backlog?

    That should be a regular exercise and be done at least once a week.

14. On how many user stories are you working in parallel during backlog grooming?

    Generally, the product owner should not make the team work on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories, that may never make into a sprint backlog, becomes too high.

15. How long does the grooming of a typical user story take?

    The grooming should not extend over the period of one to two sprints.

16. How are you creating user stories? (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 user stories which then get estimated by the team. I strongly suggest, however, to turn user story creation into a join effort of the whole team to create a shared understanding.

17. How are you discussing user stories? Only during grooming sessions or also on Slack or via comments on tickets, for example?

    Every team has its own 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 a user story is selected for a sprint backlog, this should be fine if the product owner agrees, too. Discussing its essentials during the sprint is a problem, though.

18. Are you changing user stories once they become an item 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 user story then still delivers a value. Making it larger after the sprint planning is, however, not acceptable.

19. When do you accept user stories?

    Ideally, the product owner would do so during the sprint as soon as the team/the engineer considers the user story “done”.

20. Have you ever rejected user stories?

    If that is the case, you really like to learn why that happened, and what measures where taken to prevent that from happening again.

Conclusion

The interview script helps an initial conversion between 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 best practices of product delivery.

What suitable questions am I missing? Please, let me know, so that the list can be extended.

Related Posts

20 Questions a New Scrum Master Should Ask Her Team to Get up to Speed

Agile Failure Patterns In Organizations

Hiring: 38 Scrum Master Interview Questions To Avoid Agile Imposters

Subscribe to Our “Food For Thought” Weekly Newsletter and Follow Us on Twitter

If you like to receive a curation of the best posts on agile and lean methodologies, and product management every Sunday, subscribe to our hand-curated newsletter ?Food for Thought“