Scrum Master Interview Questions (4): From Agile Metrics to Scrum Kick-off to Scrum Anti-Patterns

TL; DR: Scrum Master Interview Questions (4)

Some time ago, someone on Reddit asked whether there would be any other profession that requires attending a 2-day training class and would then pay as well as a Scrum Master job. This attitude is precisely why the 47 Scrum Master Interview Guide exists: Prevent imposters from slipping through the hiring process and causing damage.

If you are looking to fill a position for a Scrum Master (or agile coach) in your organization, you may find the following 47 interview questions useful to identify the right candidate. They are derived from my fourteen years of practical experience with XP as well as Scrum, serving both as Product Owner and Scrum Master as well as interviewing dozens of Scrum Master candidates on behalf of my clients.

So far, this Scrum Master interview guide has been downloaded more than 19,000 times.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 36,000-plus other subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

Scrum Master Interview Questions: How We Organized Questions and Answers

The ebook provides both questions as well as guidance on the range of suitable answers. These should allow an interviewer to deep dive into a candidate’s understanding of Scrum and her agile mindset. However, please note that:

• The answers reflect the personal experience of the authors and may not be valid for every organization: what works for organization A, is likely failing in organization B
• There are not suitable multiple choice questions to identify a candidate’s agile mindset given the complexity of applying “agile” to any organization
• The authors share a holistic view of agile methodologies: agile equals product discovery (what to build) plus product delivery (how to build it).

Please find following 47 Scrum Master interview questions to identify suitable candidates for the role of Scrum Master or agile coach.

Cannot see the form?
Please click here

VI. Agile Metrics

Question 39: Volatile Velocity

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.

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!

Read more: Scrum: The Obsession with Commitment Matching Velocity.

Question 40: Suitable Agile Metrics

What suitable agile metrics have you used in the past?

This question is an invitation to the candidate to share lessons learned from the successful application of metrics to help a Scrum Team improve continuously.

Suitable agile metrics follow three rules:

• The first rule of tracking meaningful metrics is only to track those that apply to the team. Ignore those metrics that measure the individual.
• The second rule of tracking metrics is not to measure parameters just because they are easy to follow. This practice often is a consequence of using various agile tools that offer out-of-the-box reports.
• The third rule of tracking metrics is to record context as well. For example, data without context, the number of available team members, or the intensity of incidents during a sprint may turn out to be nothing more than noise.

Examples of suitable agile metrics are:

• Lead time,
• Cycle time,
• Number of defects escaping to production, or
• Ratio of fixing work to creating new value.

Good candidates should be aware of the evidence-based management concept.

Question 41: Qualitative Metrics

What qualitative agile metrics would you consider tracking?

The purpose of qualitative metrics is to gain insight into how one or more of an organization’s Scrum Teams are progressing with agile.

There are several self-assessment tests available that a Scrum Team can regularly run to collect qualitative metrics about their implementation of Scrum — Hendrik Kniberg’s Scrum Checklist is a good example. The interval to test via self-assessment is every 4–12 weeks, with teams of lesser fluency running their tests at the lower end of this range. The individual values recorded by these tests are not very important, but the trend over time is. To visualize these trends, a Scrum Master will need to aggregate the results — in the case of Henrik Kniberg’s checklist, an agile practice map may be created over time.

While self-assessment tests like Henrik Kniberg’s checklist are usually team exercises for recording implementation metrics, sentiment metrics are best captured by running anonymous opinion polls to ensure the participation of the more introverted team members.

Using opinion polls, typical questions for recording sentiment metrics include:

• What value did the team deliver in the last Sprint?
• Has the level of technical debt increased or decreased during the last Sprint?
• Are you happy working with your teammates?
• Would you recommend your employer (or client) to a friend seeking a new job?

It’s best to run opinion polls after every Sprint; these polls should only require a few seconds to complete. As with the self-assessment tests, the individual values recorded by running anonymous opinion polls are not very important — it’s the trend over time that matters. Trends derived from these polls are great points for discussion during a team’s Sprint Retrospectives.

Concerning metrics in general, your candidate should support the Agile Manifesto and its principle of transparency: all metrics should be available to all members of a Scrum Team, and largely also to those working in the product delivery organization generally.

Read more: Agile Metrics — The Good, the Bad, and the Ugly.

Join us on April 20, 2021, for a live virtual workshop on driving product innovation with the Zones of Value framework. (Participation is free.)

VII. How to Kick-Off A Transition to Scrum

Question 42: Kicking off Scrum

How would you prepare to kick-off transitioning to Scrum?

If you don’t know where you are going, any road will get you there. Your candidate should understand that an agile transition needs to have an objective and a goal — which means planning ahead.

To prepare for kicking off a transition to Scrum is to listen and observe: your candidate should express interest in interviewing as many team members and stakeholders as possible, before jumping into action. These interviews should include everyone, no matter their role — engineers, QA professionals31, UX and UI designers, product managers — in order to identify the patterns underlying current problems, failures, and dysfunction within the organization. Merging those patterns with the most pressing technical and business issues will identify the most likely objectives for the first Scrum Teams. This observation phase, during which a Scrum Master performs their interviews, will typically require between four and twelve weeks depending upon the size and structure of the organization.

The training of future team members and stakeholders should commence and run parallel to the interviews.

Creating the first Scrum Teams from the existing engineering and product departments is the second step in kicking off a transition to Scrum.

Your candidate should be able to sketch the rough plan of a transition and address common issues that might arise during kickoff.

Read more: How to Kick-off Your Agile Transition.

Question 43: Creating the First Scrum Team

How would you create the first Scrum team?

When an organization is transitioning to Scrum and at the same time dealing with significant organizational, business, and technical problems, the founding members of its Scrum Teams should be volunteers who fully understand the challenge ahead of them, rather than people pressed into service. The best volunteers are those eager to prove that becoming agile is the most effective way to reach an objective.

Candidates for the role of Scrum Master should be astute enough to suggest inviting every member of the product delivery team, as well as the C-level executives sponsoring the transition, to a kickoff meeting. The objective of a transition kickoff meeting is to support the members of the engineering and product teams in how they choose to self-organize into the first cross-functional Scrum Teams. Transition kickoff meetings can last a few hours or several days, depending upon the circumstances of a particular organization.

Despite the importance of the kickoff meeting to a Scrum transition, going much deeper into its structure will take too much time from the interview. It’s more important that your candidates embrace the idea of team self-selection and present a brief roadmap of what should happen next for the newly formed Scrum Teams.

Although somewhat dependent upon the existing skills, experience, and training of the members of an organization’s new Scrum Teams, your candidates should anticipate having to teach the very basics of Scrum following a kickoff meeting. They might propose doing this through a series of workshops or on-the-job training with exercises in Product Backlog refinement, writing user stories, estimating, creating boards, and setting up collaboration software.

Question 44: First Steps of a New Scrum Team

What do you recommend a newly formed Scrum team works on first?

The first critical issue for the majority of newly formed Scrum Teams is the existing legacy Product Backlog. Answers to this question need not reference Tuckman’s team development stages (see Question 28), additional team-building exercises, or any kind of Scrum training or workshop not concerned with the Product Backlog.

It is a rare occasion for a Scrum Master to start from scratch with a brand new team and no existing product — even more so in a nascent organization like a startup. Most often, it’s an existing product delivery organization with existing products and services that will ‘go agile’. For these cases, your candidate should point out that refining the legacy Product Backlog is the practical first step.

The legacy Product Backlog per se is an interesting artifact because it provides a comprehensive insight into the product delivery organization’s history: this particular Product Backlog allows for identifying organizational debt, process insufficiencies, questionable product decisions, and other anti-patterns.

Looking at a legacy Product Backlog, an excellent candidate will be able to point out some of these anti-patterns (e.g. outdated or poorly maintained tickets), and provide a good idea about how to transform the legacy Product Backlog into a well-refined, current Product Backlog such that a new Scrum Team could work with.

Candidates should mention that running Product Backlog refinement workshops creates a good opportunity to provide a new Scrum Team and Product Owner hands-on training with Scrum. This is because a Product Backlog refinement workshop will typically cover user story creation, knowledge transfer among team members, the estimation process (if applicable), introductory agile metrics, technical debt analysis, and other topics critical to the success of Scrum.

Read more: Product Backlog Refinement.

VIII. Scrum Anti-Patterns

Question 45: Scrum Master Anti-Patterns

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. There are several possibilities on how stakeholders can interrupt the flow of the team during a Sprint:
  • The Scrum Master has a laissez-faire policy regarding access to the Development Team.
  • The Scrum Master does not object when management invites engineers to random meetings as subject matter experts.
  • Lastly, the Scrum Master allows either the stakeholders or managers to turn the daily Scrum into a reporting session.
• 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.
• : 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.

Read more: Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help.

Question 46: Sprint Retrospective Anti-Patterns

What anti-patterns do you know of that can happen during a Sprint Retrospective?

Typical Scrum Sprint Retrospective anti-patterns are:

• Waste of time: The team does not collectively value the Sprint Retrospective. If some team members consider the Sprint Retrospective to be of little or no value, it is most often the Sprint Retrospective itself that sucks. Is it the same procedure every time, ritualized and boring? Have a meta-Sprint Retrospective on the Sprint Retrospective itself. Change the venue. Have a beer- or wine-driven Sprint Retrospective. There are so many things a Scrum Master can do to make Sprint Retrospectives interesting and valuable again, reducing the absence rate. Furthermore, it is good to remember that (in my experience) introverts like to take part in Sprint Retrospectives also.
• Prisoners: Some team members only participate because they are forced to team up. Don’t pressure anyone to take part in a Sprint Retrospective. Instead, make it worth their time. The drive to continuously improve as a team needs to be fueled by intrinsic motivation, neither by fear nor by order. Tip: Retromat’s “Why are you here?” exercise is a good opener for a Sprint Retrospective from time to time.
• Groundhog day: The Sprint Retrospective never changes in composition, venue, or length. In this case, the is that the team will revisit the same issues over and over again – it’s like Groundhog Day without the happy ending.
• Let’s have it next Sprint: The team postpones the Sprint Retrospective into the next Sprint. Beyond the “inspect & adapt” task, the Sprint Retrospective serves as a moment of closure, helping reset everybody’s mind so that the team can focus on the new Sprint goal. That is the reason why we have the Sprint Retrospective before the planning of the follow-up Sprint. Postponing it into the next Sprint may also interrupt the flow of the team, and delay tackling possible improvements by up to a Sprint. This is why it is important to have the Sprint Retrospective before the planning of the follow-up Sprint.
• #NoDocumentation: No one is taking minutes for later use. A Sprint Retrospective is a substantial investment for many reasons and should be taken seriously. Taking notes and photos supports the process.
• No psychological safety: The Sprint Retrospective is an endless cycle of blame and finger-pointing. The team wins together, the team loses together. Unfortunately, the blame game documents both the failure of the Scrum Master as the facilitator of the Sprint Retrospective as well as the team’s lack of maturity and communication skills.
• Bullying: One or two team members are dominating the Sprint Retrospective. This communication behavior is often a sign of either a weak or uninterested Scrum Master. The Sprint Retrospective needs to be a safe place where everyone–introverts included–can address issues and provide their feedback free from team members who are dominating the conversation, bullying or intimidating other teammates. The failure to provide a safe place will result in participants dropping out of the Sprint Retrospective and render the results obsolete. It is the main responsibility of the Scrum Master to ensure that everyone can be heard and has an opportunity to voice their thoughts. According to Google, equally distributed speaking time fosters and signifies a high-performing team. Read More: “What Google Learned From Its Quest to Build the Perfect Team.”
• Stakeholder alert: Stakeholders participate in the Sprint Retrospective. There are plenty of Scrum events that address the communication needs of stakeholders: the Sprint Review, the Product Backlog refinement, the Daily Scrum events – not to mention opportunities of having a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is still not sufficient, feel free to have additional meetings. However, the Sprint Retrospective is off-limits to stakeholders.
• Passivity: The team members are present but are not participating. There are plenty of reasons for such a behavior: they regard the Sprint Retrospective as a waste of time, it is an unsafe place, or the participants are bored to death by its predictiveness. The team members may also fear negative repercussions should they be absent, or maybe a homogenous group of introverts was unwittingly hired. Whatever the reason, there is likely no quick fix. The Scrum Master needs to determine what style of Sprint Retrospective will work best in their organization’s context.

Read more: : 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams.

Question 47: Improving as a Scrum Master

How can you (as a Scrum Master) identify where you need to improve?

This is a simple question: Regularly ask your team and stakeholders how you can improve as a Scrum Master.

Why not run a Sprint Retrospective on yourself? A dedicated Sprint Retrospective is much more effective than spending five minutes, asking for hints at how you might improve, at the end of each regular team Sprint Retrospective.

Good candidates also note that they proactively provide user manuals on how to work with themselves to other team members and the organization.

📖 Recommended Articles

Peer Recruiting: How to Hire a Scrum Master in Agile Times

Download the ’Scrum Anti-Patterns Guide’ for Free

The Scrum Master Trends Report 2019

22 Scrum Master Anti-Patterns from Job Ads

Lipstick Agile — 15 Signs You Probably Need a New Job or to Roll-up Your Proverbial Sleeves

Speaking Truth to Power 2.0 — Taking A Stand as an Agile Practitioner

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

✋ Do Not Miss Out and Learn more about the Scrum Master Interview: Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Team

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.