Scrum Master

Interview Guide I
10 Questions in 30 Minutes to
Identify Suitable Candidates
1. Is the Scrum Master Role
a Contradiction?
Q: The Agile Manifesto infers people over processes.
Isn’t a Scrum Master — whose role is meant to
“enforce” the process — therefore a contradiction?

Scrum Masters do not wield any absolute authority but act

as servant leaders. The Scrum Team does not report to them.
This question is meant to help reveal whether your candidate
understands that their role is to lead — as opposed to
managing — the team. Asking this question is also likely to
show why your candidate is interested in the role of a Scrum
Master in the first place.

Acceptable answers should emphasize facilitation and

support, for example:

“I am the servant-leader for the Scrum Team. It’s my job

to make them successful.”
“I am neither a project manager nor a people manager. I
support the Scrum Team in achieving self-management. I
do not tell people what, when, or how to do things.”
“I am the Scrum Team’s facilitator as teacher, coach, or
mentor, encouraging them to excel as a team.”

Check out the free Scrum Anti-Patterns Guide.

 2. External Requirement
Documents

Q: The Product Owner for your Scrum Team frequently

turns requirements documents received from
stakeholders into tickets and asks you to estimate
each. How do you feel about this procedure?

A Product Owner should not take this shortcut and turn

requirements documents received from stakeholders into
work items, and a Scrum Master should never accept such a
procedure. It’s nothing more than a waterfall process
dressed-up as a pseudo-agile practice.

If an organization is supposed to focus on delivering value to

its customers, it is essential that any process involving
’requirements’ being handed down to its engineers by a
project manager be abandoned. It makes no difference if the
project manager is posing as a Product Owner. Instead, the
organization should start including everyone in the product
discovery process, thereby ensuring a shared vision of what
needs to be built.

Check out the free Scrum Anti-Patterns Guide.

 3. Organizing the Sprint
Planning
Q: How would you organize the Sprint Planning?

This open-ended question allows the applicant to share war

stories from the trenches and their general idea of how a
Scrum team should handle Sprint Planning.

One way to organize a Sprint Planning is:

1. The Product Owner introduces the business objective for

the new Sprint. (From the Scrum Guide: “The Product
Owner proposes how the product could increase its value
and utility in the current Sprint.”)
2. The whole Scrum team creates a corresponding Sprint
Goal.
3. The Developers commit to the Sprint Goal.
4. Moreover, they identify necessary work items to
accomplish the Sprint Goal, most likely from the Product
Backlog. Alternatively, they create new work items.
5. Probably, the Developers also refine work items, if
necessary, and plan how to accomplish them.
6. We refer to the package of Sprint Goal, selected Product
Backlog item, and their delivery plan as the Sprint
Backlog.
Check out the free Scrum Anti-Patterns Guide.
 4. The Formal Daily Scrum

Q: Would you recommend formal Daily Scrums for all

teams, no matter the size or experience level?

In answering this question, your candidate should exhibit

common sense regarding “ritualized” Daily Scrums. Daily
Scrums are an important part of Scrum, but not all Daily
Scrums need to be formal — a Development Team should not
have a Daily Scrum for the sake of having it; it serves a
different purpose than ticking off a box on a checklist. A
small, experienced, and co-located team may use a morning
coffee break for their Daily Scrum.

Nevertheless, the Daily Scrum is the essential inspect &

adapt event of the Development Team: are we still on track
accomplishing the Sprint Goal? Or have we learned
something since the previous Daily Scrum that requires to
change our plan of how to achieve the Sprint Goal?

Check out the free Scrum Anti-Patterns Guide.

 5. A Sprint Review without
Stakeholders?
Q: Again, at the end of the Sprint, none of your
stakeholders is joining the Sprint Review. Shall the
team have it anyway, although they are familiar with
the outcome?

Firstly, no matter whether the Scrum team members already

know the outcome, the team should have the Sprint Review.
Skipping events is a slippery slope: Once you start, you may
become accustomed to it, diminishing the Scrum team’s
prospects slowly but steadily.

Secondly, the Scrum team should start understanding why

no stakeholders participate. For example, start by figuring
out the answers to the following questions:
Do the stakeholders understand the Sprint Review’s
importance for creating value for the customers?
Do they know that the Sprint Review is happening?
Is the date of the Sprint Review colliding with other
important meetings?
Does the Scrum team run the Sprint Review in a way that
appeals to the stakeholders? Do the stakeholders feel
seen, heard, and appreciated?
Is someone interfering with the Scrum team’s desire to
invite (external) stakeholders? For example, the
salespeople might object to the idea of asking customers
to the Sprint Review.
 Demand Creates Supply and the
Job Market for Agile Practitioners
Is No Exception

Scrum has proven time and again to be the most

popular framework for software development. Given
that software is eating the world, a seasoned Scrum
Master is nowadays in high demand.

And that demand causes the market-entry of new

professionals from other project management
branches, probably believing that reading one or two
Scrum books will be sufficient. Which makes any Scrum
Master interview a challenging task.

Suppose you are looking to fill a Scrum Master position

in your organization.

In that case, you may find the following Scrum Master

interview questions helpful to identify the right
candidate. They are derived from my seventeen years
of practical experience with XP and Scrum, serving both
as Product Owner and Scrum Master, and my training
experience as a Professional Scrum Trainer with
Scrum.org. Also, I have interviewed dozens of Scrum
Master candidates on behalf of my clients.
 How to Use the Interview Questions

This document provides questions and guidance on the

range of suitable answers. These should allow an
interviewer to dive deep into a candidate’s
understanding of Scrum and their agile mindset.

However, please note that:

The answers reflect the personal experience of the

author and may not be valid for every organization: what
works for organization A is likely failing in organization B.

There are no relevant multiple choice questions to

identify a candidate’s agile mindset given the complexity
of applying “agile” to any organization.

The author has a holistic view of agile practices: agile

equals product discovery (what to build) plus product
delivery (how to build it) as a collaborative exercise of the
whole Scrum team.

The Scrum Master interview questions are not

necessarily suited to turn an inexperienced interviewer
into an agile expert.

But in the hands of a seasoned practitioner, they

support figuring out, what candidate has been working
the agile trenches in the past.

So, go for a pragmatic veteran who has experienced

failure before and the scars to prove it.
 Categories of Interview Questions

This Scrum Master interview guide comprises

questions from the following categories:

1. The Role Of The Scrum Master

2. Product Backlog Refinement And Estimation
3. The Sprint Planning
4. The Daily Scrum
5. The Sprint Review
6. The Sprint Retrospective
7. Agile Metrics
8. How to Kick-Off A Transition to Scrum
9. Scrum Anti-Patterns
10. Scrum Success Principles and Indicators
11. How to Make Your Scrum Master Fail
 How to Download a
PDF from your
LinkedIn Feed:

(1) Hover with the pointer over the

document. In the lower right corner, click
on this icon:

(2) Once you are in full-screen mode,

download the PDF by clicking this icon

in the upper right corner.

 6. Team Health

Q: Should you check a team’s health during a Sprint

Retrospective, or is doing so unnecessary? If you do,
how would you go about it?

Measuring the health of a Scrum Team — that is, getting an

idea about current levels of engagement and satisfaction —
is useful for identifying trends that may affect productivity
and team cohesion.

For example, one effective method of measuring the health

of a Scrum Team is to circulate an anonymous multiple-
choice questionnaire before the team’s Sprint
Retrospectives. A questionnaire that requires just two
minutes to complete and uses a simple scale for each of the
questions — from 1 (terrible) through 2 (poor), 3 (neutral), 4
(good), to 5 (excellent) — is usually well-suited.

During the Sprint Retrospective, the team should discuss the

results with an aim to uncover any concerns or frustrations
they may be harboring. (See above, gathering data.)

Check out the free Scrum Anti-Patterns Guide.

 7. Volatile Velocity I

Q: Your Scrum team is consistently failing to meet

commitments, and its velocity is volatile. What might
the possible reasons be? How would you address this
issue with the team?

If a Scrum Team is exhibiting a volatile velocity, consistently

failing to meet their forecasts, it suggests that velocity is
being used as the prevalent metric for measuring that team’s
progress.

Your candidate should mention this, and talk about the

notoriety of ‘velocity’ as the industry’s most prevalent
metric for measuring a team’s progress. They should further
be able to explain why velocity is altogether a doubtful agile
metric and point out that quantitative metrics are not ideally
suited to measuring a team’s progress in mastering Scrum.

(Continued on the next page.)

Check out the free Scrum Anti-Patterns Guide.

 7. Volatile Velocity II
Conclusion:

There are many factors that make a Scrum Team’s velocity

volatile:

New team members being onboarded;

Experienced members leaving the team;
The team working in uncharted territory;
The team working with legacy code, probably
undocumented;
The team running into unexpected technical debt;
Holidays and sick leave reducing the team’s capacity;
An executive intervention changing a Sprint’s scope; and
The team addressing unplanned priority bugs.

Another common cause for a Scrum Team to consistently fail

in meeting their forecasts is that the team’s Product Backlog
items are being poorly prepared, thus making the work items
difficult for the team to estimate. Conversely, the projects
being given the team might suffer from poorly documented
legacy code, excessive technical debt, or just too much
buggy and poorly written code — all of which make
estimation a gamble.

Your candidate should not align themselves with the fallacy

that a team’s adoption of Scrum is working only because a
Scrum Team’s forecasts and velocity are aligned. Cooking the
agile books is easy to do!
 8. Scrum Master Anti-
Patterns I
Q: What anti-patterns might a Scrum Master fall into
during a Sprint?

Typical Scrum Master Sprint anti-patterns are below. Any of

these behaviors will impede the team’s productivity. It is the
Scrum Master’s obligation to prevent them from manifesting
themselves. Some of the Scrum Master anti-patterns are:

Keeping the Scrum team dependent: In this scenario, the

Scrum Master pampers the team to a level that keeps the
team dependent on his or her services: organizing
meetings, purchasing stickies and sharpies, taking notes,
updating Jira—you get the idea of this service level. More
critical, however, is when the Scrum Master decides to
keep the team in the dark about principles and practices
to secure his or her job. This behavior is only a small step
away from the dark side.

Flow disruption: The Scrum Master allows stakeholders

to disrupt the workflow of the Development Team during
the Sprint.

(Continued on the next page.)

 8. Scrum Master Anti-
Patterns II
Lack of support: The Scrum Master does not support
team members who need help with a task. Development
teams often create tasks an engineer can finish within a
day. However, if someone struggles with a task for more
than two days without voicing that they need support,
the Scrum Master should address the issue. Importantly,
this is also the reason for marking tasks on a physical
board with red dots each day if they haven’t been moved
on to the next column.
Turning a blind eye to micromanagement: The Scrum
Master does not prevent the Product Owner – or anyone
else – from assigning tasks to engineers. The
Development Team normally organizes itself without
external intervention. And the Scrum Master should act
as the shield of the team in this respect.
Focusing on team harmony: The Scrum Master sweeps
conflict and problems under the rug by not using Sprint
Retrospectives to address those openly. This behavior is
often a sign of bowing to politics and instead of using
manipulation to meet organizational requirements that
are opposing Scrum values and principles. If the
organization values its underlings for following the ‘rules’
instead of speaking the truth why would you run
Retrospectives in the first place? A ‘Scrum Master’
participating in cargo-cult Scrum is again a supervisor
than an agile practitioner.
9. Scrum Master Success
Q: How could you measure the success of a Scrum
Master?

There are several indicators of the success of a Scrum

Master, for example:

The Scrum team regularly meets Sprint Goals and

delivers valuable, done Increments.
They have an excellent understanding of the Scrum
framework and the challenges it poses to individuals and
organizations.
They are prepared to step into the background when the
Scrum team is successful.
The successful Scrum Master strives to become
redundant concerning the daily operations of the Scrum
Team. (A successful Scrum Master can take a holiday at
any time, just saying.)
They spend more and more time on working with the
organization while the Scrum team is self-managing.
The Scrum team has high morale; rarely, a team member
leaves the team, but others want to join it.
The whole Scrum team is dedicated to continuously
improve their skills and capabilities, branching out into
adjacent areas of the organization in the process.

Check out the free Scrum Anti-Patterns Guide.

 10. How to Make Your
Scrum Master Fail
Q: How can you mess with the Scrum framework itself
to make your Scrum Master fail?

The first category of how to best sabotage a Scrum Master is

generally about disqualifying Scrum itself as a helpful
framework or introducing changes to conflict with the first
principles of Scrum. Effective examples are:

Place the blame on Scrum whenever you can, even if it is

technically unrelated.
If Scrum uncovers an obstacle in the organization, blame
that on Scrum.
Find examples of where Scrum failed in other companies
to spread around.
Talk disrespectfully in the coffee breaks with developers
and the other middle managers about Scrum and the role
of the Scrum Master.
Challenge anything the Scrum Masters try to say or do.
Ignore the Scrum Master’s offer to learn about Scrum.
Create an ego-centric incentive system.
Install multiple Product Owners in a Scrum Team.
Place a proxy Product Owner in the Scrum Team and
overrule all decisions.
Coming soon…
 Join 46,000 Peers
and Subcribe to the
Food for Agile
Thought Newsletter

https://bit.ly/m/StefanW
Get Your Free Copy of
the Scrum Anti-
Patterns Guide:
https://age-of-product.com/scrum-
anti-patterns/
 Connect with me:

https://bit.ly/m/StefanW