TL; DR: 20
Questions a New Scrum Master Should Ask
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.
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.
The
questionnaire I used as is available as a download for your convenience:
Let us get into the questions for a new professional scrum master training at tryScrum:
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.
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.)
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.)
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.
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.
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 into a Sprint
Backlog becomes too high.
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.
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?
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.
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.
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 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.
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.
What was your
velocity for the last three Sprints?
A Scrum Team
should know its velocity or productivity, how could it otherwise possibly
improve?
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.
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.
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?)
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.
Conclusion
The New Scrum Master and the Scrum Team
What is your preferred technique to get familiar with a new Scrum Team as soon as possible? Where do you start? Please share your experience in the comments.
Resource:
https://www.scrum.org/resources/blog/20-questions-new-scrum-masters-should-ask-their-teams-get-speed
