60 Questions for the New Scrum Master—

Get up to Speed with a New Scrum Team

by Stefan Wolpers
Version: 1.0 | 2021-07-05
Table of Content
INTRODUCTION ............................................................................................................................... 3

20 QUESTIONS NEW SCRUM MASTERS SHOULD ASK THEIR TEAMS TO GET UP TO SPEED ....... 4

20 QUESTIONS FROM NEW SCRUM MASTER TO THE PRODUCT OWNER ................................... 7

20 QUESTIONS FROM NEW SCRUM MASTER TO THE DEVELOPERS .......................................... 11

PRINTABLE QUESTIONNAIRES ....................................................................................................... 14

20 Questions from New Scrum Master to the Scrum Team ................................................................................. 14

20 Questions from New Scrum Master to Product Owner ................................................................................... 16

20 Questions from New Scrum Master to the Developers ................................................................................... 18

ABOUT THE AUTHOR ..................................................................................................................... 20

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 2 of 20
Introduction
Congratulations to your new Scrum Master position! Now what?

What has served me well over the years is a combination of observation and asking
questions. The following 60 Questions for a New Scrum Master may support you in learning
more about the Scrum team’s way of working and the organization’s culture.

The questions are intended as a starter to get a new Scrum Master airborne in a short
period. Depending on how familiar your team is with Scrum, the kind of the team’s
organization and its culture, and the market your Scrum team is serving, this set of questions
may require change.

The questions have proven helpful in 1-on-1 conversation, in group discussion, and the form
of an anonymous survey. But, no matter the format, the questions pave the way for a new
Scrum Master to gather insight into the Scrum team’s way of working and the organization’s
culture they need to start to support the team.

The answers also provide a sound basis for a team Retrospective.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 3 of 20
20 Questions New Scrum Masters Should Ask Their Teams to
Get up to Speed
Twenty questions for you — the new Scrum Master — that fit into a 60 minutes time-box.
Start learning how your new Scrum Team is currently delivering the product and get up to
speed: from Product Backlog forensics to metrics to team challenges and technical debt.
Download a printable template for your convenience.

Do you need to talk to your Product Owner? Here you go: 20 Questions from New Scrum
Master to Product Owner.

Start Learning the Ropes as a New Scrum Master

I was recently asked to participate in the Product Backlog refinement of a team that was
looking for a new Scrum Master. I was skeptical in the beginning. I had only limited
knowledge about the project—a commercial website based on a CMS—, the refinement
session was time-boxed to 60 minutes, and I hadn’t met the team members before beyond a
very brief “hello.”

So, I prepared a questionnaire comprising team-related topics. I wanted to learn more about
and listened to the Scrum Team, refining several work items. When appropriate, I asked one
of the prepared questions. Surprisingly, the insights turned out to be much more qualified
than I expected. Particularly, I could identify the low-hanging “Scrum fruits” to improve
product delivery relatively easily. Remember that as a Scrum Master, the stakeholders will
always judge you by whether “your Scrum Team” can deliver a valuable, potentially
releasable, “done” Product Increment regularly.

Let us get into the questions for a new Scrum Master:

1. 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 of some
support.

2. What is the typical age of a Product Backlog item? A Product Backlog item that has
not been touched in five months is obsolete. Cluttering the Product Backlog with
ideas, reminders, or other low-value items increases the noise, thus probably
impeding the value delivery of the Scrum Team. (Admittedly, I am a fan of Product
Backlog forensics.)

3. What is your average lead time from an idea being added to the Product Backlog to
its delivery? No one could answer that question in the before-mentioned session.
But it is actually one of only a few metrics that can provide some insight on whether
Scrum has been successfully adopted by your organization. (Read more: Agile Metrics
— The Good, the Bad, and the Ugly.)

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 4 of 20
 4. Does your Product Backlog contain work items none of the current team members
is familiar with? If so, the Product Backlog items in question may no longer be
valuable. Consider re-refining or deleting them.

5. How often are you refining the Product Backlog? That should be a continuous
process. As a new Scrum Master, however, I would love to have a Product Backlog
refinement session once a week with the whole team.

6. On how many Product Backlog items are you working in parallel during Product
Backlog refinement? Ideally, a team should not be working on more work items than
it can handle within the next two or three Sprints. Otherwise, the risk of allocating
resources on work items that may never make it into a Sprint Backlog becomes too
high.

7. How long does the refinement of a typical Product Backlog item take? The
refinement should not be taking more than one to two Sprints. Otherwise, the
Product Owner might need some support in preparing ideas properly for the
refinement sessions.

8. How are you creating Product Backlog items? (Is it a joint team effort with the PO,
or is the Product Owner writing the work items and the Development Team
estimates them?) There is a tendency to observe that Product Owners become more
a kind “technical writer” of Product Backlog items, which then get estimated by the
team. I suggest, however, to turn Product Backlog item creation into a joint effort of
the whole team. Remember Ron Jeffries’ CCC: card, conversation, confirmation?

9. Where are you discussing Product Backlog items? (Only during refinement 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 work item is selected for a Sprint Backlog, this should be fine. Discussing its
essentials afterward is a problem, though, as the Sprint Goal might be compromised.
10. Who is writing acceptance criteria and in what format? It should be the Product
Owner in collaboration with the Development Team following the Definition of
“Done,” thus creating a shared understanding of what the team needs to build.

11. How are you estimating the likely effort of a Product Backlog item? There are
plenty of practices on estimating a work item if your Scrum Team estimates at all.
(Think of #noestimates or creating similarly sized work items instead.) The emphasis
should be on creating a shared understanding among all team members what shall
be created. An estimate is a side-effect, not the primary purpose.

12. Are you estimating in man-hours or story points? Estimating in man-hours is better
than not estimating at all. However, I prefer story points, particularly if the
application in question is burdened with legacy code and/or technical debt.
Predictability and stakeholder communications become easier this way as story
points have a built-in buffer.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 5 of 20
 13. How are you practicing the estimation process if the team shares different
opinions? Preferably, you should observe the team’s estimation process in real life.
But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and
how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one
do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g.
from 2 to 8?) It is a good way to learn more about the team building state, too.

14. What is a typical distribution of work item sizes in your Sprint Backlog? This
question tries to figure out, where the productivity sweet spot of the team is, based
on the Sprint Backlog composition. In my observation, Scrum Teams often work more
successfully when a Sprint Backlog comprises one or two larger Product Backlog
items, some medium-sized stories, and a few small ones.

15. Are you re-estimating work items at the end of a Sprint? If so, under which
circumstances are you doing so? That should always be done if a Product Backlog
item turns out to be way off its original estimation. Re-estimates make good data-
points for Sprint Retrospectives, too.

16. What was your velocity for the last three Sprints? A Scrum Team should know its
velocity or productivity, how could it otherwise possibly improve?

17. How many user stories are typically not finished within a Sprint and for what
reasons? If the team is bullish and picked more Product Backlog items than it could
probably handle at the beginning of the Sprint, so be it—nothing to worry about if
the Development Team meets the Sprint Goal nevertheless. If the Development
Team, however, is regularly leaving work items on the board and not meeting Sprint
Goals, this should be a major concern for the new Scrum Master. See also: Scrum:
The Obsession With Commitment Matching Velocity.

18. Are you changing Product Backlog items once they become part of a Sprint
Backlog? And if so, under what circumstances? Making work items smaller if the
Development Team runs into a problem is certainly not great, but acceptable—if the
work item in its reduced form still delivers value and the Sprint Goal is met.
Extending it after the Sprint Planning, however, would only be tolerable if the
Development Team agrees on the extension, and the Sprint Goal will not be
compromised.

19. How would you consider the level of technical debt? As a new Scrum Master, you
want to know everything about the current level of technical debt and dependencies
on other Scrum Teams or external suppliers. These issues are directly responsible for
your Scrum Team’s ability to deliver product Increments. (Read more: Technical Debt
& Scrum: Who Is Responsible?)

20. What are the three main challenges the Scrum Team is facing today? This closing
question is by design an open-ended question to get some ideas for the next Sprint
Retrospective.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 6 of 20
20 Questions from New Scrum Master to the Product Owner
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.

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.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 7 of 20
As Scrum Masters, we better make sure to support our Product Owners the best we can to
serve our Scrum Team to become successful.

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:

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 vision or strategy
questions 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 product discovery.

4. How much time do you allocate to 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.

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

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 refinement
sessions to explain the value of a user story. Learn more: 11 Proven Stakeholder
Communication Tactics.

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

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.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 8 of 20
 9. How large is your Product Backlog? I do not believe in the usefulness of 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.

10. 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 into
how the organization works: number of 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.)

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

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

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

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

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

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

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

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 9 of 20
 Product Owner agrees, too. Discussing its essentials during the Sprint for the first
time might be a problem, though.

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

19. 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.”

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

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 10 of 20
20 Questions from New Scrum Master to the Developers

From Scrum Master to Development Team members, this set of questions addresses the
foundations of a Scrum Team capability to build valuable products: technical excellence and
what it takes to achieve this proficiency level. The questions have been modeled after some
basic principles that high performing teams have in common—from keeping technical debt
at bay to collaboratively creating a Product Backlog.

The following questionnaire has proven useful in a team discussion or as a guide during an
individual interview or as the basis for an anonymous survey. In either way, the 20 Questions
from New Scrum Master to the Development Team get the discussion going. The
questionnaire comprises three topics:

 Who is creating your Definition of ‘Done?’ Typically, it is either the development

organization or the Development Team. The question is an excellent bridge to
learning about the Definition of ‘Done’ in general; for example, has it regularly
inspected and adapted?

 How would you consider the level of technical debt? As a new Scrum Master, you
want to know everything about the current level of technical debt and dependencies
on other Scrum Teams or external suppliers. These issues are directly responsible for
your Scrum Team’s ability to deliver product Increments. (Read more: Technical Debt
& Scrum: Who Is Responsible?)

 Are you tracking the development of technical debt regularly? I would expect an
experienced Development Team to a) have a good understanding of the current level
of technical debt and b) visualize technical debt to ensure its inclusion in any product
decisions.

 How much time per Sprint do you allocate to refactoring and bug fixing? First of all,
the need for refactoring and bug fixing should be understood by the organization in
general; otherwise, you might be working in a feature factory. Secondly, as a rule of
thumb, I would expect the Development Team to spend at least 20 % of their
capacity on keeping technical debt at bay to ensure the path to a sustainable level of
business agility.

 How are you spreading knowledge among the Development Team members, how
are you improving your technical excellence level? I would assume that the
Development Team embraces techniques like pair or mob programming, code
mentors, brown bag session, hackathons, etc. If they are not yet practicing those,
there is room for improvement.

 Do you have any skill gaps that would require formal training classes to improve
your team’s effectiveness? This question is preparing the Scrum Master for the
discussion with the development organization or IT management. A Development
Team’s struggle—typical indicators are, for example, missed Sprint Goals, a lot of
bugs in the product environment, or a substantial lead time to roll-out a new

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 11 of 20
 functionality—might result from a lack of technical knowledge. The allocation of a
training budget to the team might hence the way out of the misery.

 Do you have the right tools available—software, hardware, cloud applications—to

accomplish the team’s mission? This question is self-explanatory but points to a
critical impediment the Development Team might be facing: inadequate tools for the
job it is expected to accomplish. More food for thought for the new Scrum Master to
prepare the discussion with the management.

 Are you involved in the hiring process of new Development Team members? I
believe that the Development Team members shall have the final say over who is
joining their team. It defies the basic principle of self-organization if outsiders can
determine the team’s composition. (Read more: Peer Recruiting.)

 At what stage do you participate in the product discovery process? It is highly

recommended to involve the Development 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.

 Have you ever interviewed customers of our product to learn more about their
needs? In most cases, when Development Team members haven’t yet had direct
contact with customers of their product, it is a sign of a flawed process not leading to
an actionable Product Backlog, thus limiting the Scrum Team’s success potential in
the long run. There are plenty of reasons for that: Functional silos within the
organization are not collaborating, the Product Owner is not taking collaborative
Product Backlog creation seriously, or there is no “Product Owner” in the first place
as a steering committee is handling the product design, or the industrial paradigm is
still ruling: coders have to code, the business analysts can do the talking, right?

 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 have the Development
Team refine 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

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 12 of 20
 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.

 Is your Product Owner changing work items once they become a part of a Sprint
Backlog? And if so, under what circumstances? Well, making them smaller, if the
Development 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 paramount that the Product Owner respects the
Development Team’s prerogative to control the composition of the Sprint Backlog.

 How are you estimating the likely effort of a Product Backlog item? There are
plenty of practices on estimating a work item if your Scrum Team estimates at all.
(Think of #noestimates or creating similarly sized work items instead.) The emphasis
should be on creating a shared understanding among all team members what shall
be created. An estimate is a side-effect, not the primary purpose.

 Are you estimating in man-hours or story points? Estimating in man-hours is better

than not estimating at all. However, I prefer story points, particularly if the
application in question is burdened with legacy code and/or technical debt.
Predictability and stakeholder communications become easier this way as story
points have a built-in buffer.

 How are you practicing the estimation process if the team shares different
opinions? Preferably, you should observe the team’s estimation process in real life.
But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and
how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one
do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g.
from 2 to 8?) It is a good way to learn more about the team building state, too.

 What are the three main challenges the Development Team is facing today? This
closing question is by design an open-ended question to get some ideas for the next
Sprint Retrospective.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 13 of 20
Printable Questionnaires
20 Questions from New Scrum Master to the Scrum Team

1. How large is your Product Backlog?

2. What is the typical age of a Product Backlog item?

3. What is your average lead time from an idea being added to the Product Backlog to
its delivery?

4. Does your Product Backlog contain work items none of the current team members is
familiar with?

5. How often are you refining the Product Backlog?

6. On how many Product Backlog items are you working in parallel during Product
Backlog refinement?

7. How long does the refinement of a typical Product Backlog item take?

8. How are you creating Product Backlog items?

9. Where are you discussing Product Backlog items?

10. Who is writing acceptance criteria and in what format?

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 14 of 20
 11. How are you estimating the likely effort of a Product Backlog item?

12. Are you estimating in man-hours or story points?

13. How are you practicing the estimation process, if the team shares different opinions?

14. What is a typical distribution of work item sizes in your Sprint Backlog?

15. Are you re-estimating work items at the end of a Sprint? If so, under which
circumstances are you doing so?

16. What was your velocity of the last three Sprints?

17. How many user stories are typically not finished within a Sprint and for what
reasons?

18. Are you changing Product Backlog item once they become part of a Sprint Backlog?
And if so, under what circumstances?

19. How would you consider the level of technical debt?

20. What are the three main challenges the Scrum Team is facing today?

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 15 of 20
20 Questions from New Scrum Master to Product Owner

1. What is the product vision and the corresponding go-to-market strategy?

2. How do you learn about new ideas and requirements?

3. How do you include user research in the product discovery process?

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

5. At what stage do you involve the team members in the product discovery process?

6. How do you organize the collaboration with stakeholders?

7. How do you deal with pet projects?

8. What is your approach to creating product roadmaps?

9. How large is your Product Backlog?

10. What is the typical age of a work item in the Product Backlog?

11. What is your average lead time from picking an idea for validation to adding the
corresponding work item to the Product Backlog?

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 16 of 20
 12. Does your Product Backlog contain work items none of the current Development
Team members is familiar with?

13. How often are you refining the Product Backlog?

14. On how many work items are you working in parallel during Product Backlog
refinement?

15. How long does the refinement of a typical work item take?

16. How are you creating work items? (Is it a joint team effort?)

17. How are you discussing work items? (Only during refinement sessions or also on
Slack or via comments on tickets, for example?)

18. Are you changing work items once they become an item of a Sprint Backlog?

19. When do you “accept” work items?

20. Have you ever “rejected” work items?

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 17 of 20
20 Questions from New Scrum Master to the Developers

1. Who is creating your Definition of ‘Done?’

2. How would you consider the level of technical debt?

3. Are you tracking the development of technical debt regularly?

4. How much time per Sprint do you allocate to refactoring and bug fixing?

5. How are you spreading knowledge among the Development Team members, how are
you improving your technical excellence level?

6. Do you have any skill gaps that would require formal training classes to improve your
team’s effectiveness?

7. Do you have the right tools available—software, hardware, cloud applications—to

accomplish the team’s mission?

8. Are you involved in the hiring process of new Development Team members?

9. At what stage do you participate in the product discovery process?

10. Have you ever interviewed your customers to learn more about their needs?

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 18 of 20
 11. How often are you refining the Product Backlog?

12. On how many work items are you working in parallel during Product Backlog
refinement?

13. How long does the refinement of a typical work item take?

14. How are you creating work items? (Is it a joint team effort?)

15. How are you discussing work items? (Only during refinement sessions or also on
Slack or via comments on tickets, for example?)

16. Is your Product Owner changing work items once they become a part of a Sprint
Backlog? And if so, under what circumstances?

17. How are you estimating the likely effort of a Product Backlog item?

18. Are you estimating in man-hours, story points, or not at all?

19. How are you practicing the estimation process if the team shares different opinions?

20. What are the three main challenges the Development Team is facing today?

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 19 of 20
About the Author

Stefan is a Professional Scrum Trainer with Scrum.org, an Agile Coach, and Scrum Master.

He is specializing in coaching agile practices for change, for example, agile software
development with Scrum, LeSS, Kanban, and Lean Startup, as well as product management.

He also serves as one of the XSCALE Alliance stewards and coaches organizations in business
agility. Additionally, he is a licensed facilitator of the Agile Fluency™ Team Diagnostic.

He has served in senior leadership positions several times throughout his career. His agile
coaching expertise focuses on scaling product delivery organizations of fast-growing,
venture-capital funded startups, and transitioning existing product teams in established
enterprise organizations.

Stefan is also curating the popular ‘Food for Agile Thought’ newsletter for the global Agile
community with 32,000-plus subscribers. He blogs about his experiences on Age-of-
Product.com and hosts the most significant global Slack community of agile practitioners
with more than 10,000 members.

His ebooks on agile topics have been downloaded more than 70,000 times. Lastly, Stefan is
the organizer of the Agile Camp Berlin, a Barcamp for 200-plus agile practitioners.

Read more about Stefan at Scrum.org, and connect with him via LinkedIn, or Twitter, or
privately via email.

Copyright: Stefan Wolpers, 2021. All rights reserved. Visit us at https://age-of-product.com Page 20 of 20