Scrum Master Interview: 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.

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 17,000 times.

Do you want to get this article in your inbox? You can sign up here and join 26k other subscribers

Update 2020-09-13: Comprehensive Content Refactoring and a New Document Stack

I refactored the ebook completely, eliminating a lot of content debt, and migrated the document to a new format that will allow for much speedier updates in the future. You will also now find all questions and answers listed below, starting with the first two areas of competence.

Download the 47 Scrum Master Interview Questions PDF

The free 47 Scrum Master Interview Questions PDF is not merely listing the questions, but also contains background information on:

Why the questions are useful in the process.

A range of appropriate answers.

Two to three questions from each category will provide more than enough ground for an engaging 60 minute-long conversation with candidates.

Cannot see the form?

Please click here

The Scrum Master According to the Scrum Guide

While the Scrum Guide is sometimes detailing issues to a lesser degree, the Scrum Master role does receive appropriate attention:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Source: Scrum Guide 2017.

The Scrum Guide continues defining a Scrum Master’s services to the Product Owner, the Development Team, and the organization, which guided the creation of the following set the Scrum Master interview questions.

47 Scrum Master Interview Questions

Scrum is not a methodology, but a framework. There are no rules that apply to every scenario, just best practices that have worked in other organizations before. Hence, you have to figure out on your own what is working for your organization–which is a process, not a destination.

The role of the Scrum Master or agile coach in my understanding is hence primarily about leadership and coaching, but not about management. And most definitely, the Scrum Master role is not about process enforcement. This is also the reason, that the repository contains mostly questions that address a candidate’s soft skills. ‘Agile needs to be pulled; it cannot be pushed. (Unless your organization is planning to waste significant investments on some version of cargo cult agile, see also ‘Cargo Cult Agile: The ‘State of Agile’ Checklist for Your Organization.’)

The Scrum Master interview questions in this PDF are modeled after a holistic model of agile product development for software products:

In this model, product discovery is moved as far as possible to the left to keep costs of validating hypotheses — derived from a vision and strategy — low and increase the speed of experimentation. In this approach it is crucial that the Scrum Master coaches the scrum team to adopt such a holistic model, some call it dual-track agile, as well.

Therefore, the PDF contains additional background and contextual information, how the following set of questions can be interpreted as well as guidance on desired or acceptable ranges of answers for each question — based on such a holistic model. The questions themselves are grouped into seven categories.

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:

I. The Role Of The Scrum Master

Question 01: The Scrum Master Role as a Contradiction?

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 real 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 reveal 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-organization. I do not tell people what to do.”

“I am the Scrum Team’s facilitator as teacher, coach, or mentor, encouraging them to excel as a team.”

Question 02: Success Factors of “Agile”

What indicators might there be that demonstrate agile practices are working for your organization, and which of these would demonstrate your efforts are succeeding?

There is no standard or general definition of ‘agile success’ that can be used to measure an organization’s agility. Every organization must develop its own criteria. Increasing team velocity is usually not considered to be a meaningful indicator.

However, although mostly indirect, there are various indicators that may be useful in determining success:

Products delivered to customers are resulting in higher retention rates, better conversion rates, increased customer lifetime value, and similar improvements to the business. (A successful Scrum Team provides a good return on investment to the business.)

The improved organizational agility allows pursuing market opportunities successfully, which previously would have been considered futile.

There has been a reduced allocation of resources to low-value products.

Lead time, from validated idea to shipped product, has been reduced.

The cycle time for hypotheses validations has been reduced, speeding up the product discovery process.

Improved team happiness is exhibited by reduced churn and an increase in the number of referrals from team members.

Increased competitiveness in the war for talent can be demonstrated by an increase in the number of experienced people willing to join the organization.

Increased software quality can be demonstrated by measurably less technical debt, fewer bugs, and less time spent on maintenance.

There is greater respect among stakeholders for the product delivery teams.

Stakeholders are increasingly participating in events, for example, during the Sprint Review.

Question 03: Impediment Remover

Should a Scrum Master remove impediments on behalf of the Scrum Team?

A Scrum Master should not be concerned with removing problems that the Scrum Team can solve themselves, no matter how often this requirement is mentioned in job advertisements. If a Scrum Master acts like a ‘Scrum helicopter parent,’ their team will never become self-organizing.

A Scrum Team must learn to make its own decisions. This almost inevitably results in failures, dead-ends, and other unplanned excursions when the team is learning something new. Consequently, in the beginning, a team will need more guidance than usual from the Scrum Master — and of a different kind than exemplified by drawing offline boards (see Questions 31 and 32) or updating tickets in JIRA. Such guidance should not, however, become an exercise in protective parenting — a team must be allowed to learn from their failures.

That being said, there is one area where the Scrum Master is indeed removing problems on behalf of the team. This applies when the Scrum Team cannot solve the problem by themselves, for example, because the issue is an organizational problem. Now we are talking about “impediments.” Only in this situation, the Scrum Master becomes the impediment remover of the Scrum Team.

Question 04: Communication between Scrum Master and Product Owner

How should a Scrum Master communicate with a Product Owner?

Communicating honestly and openly is the best way for a Scrum Master to get the cooperation of a Product Owner. Both must serve as servant leaders without being authoritative, and each depends upon the other working reciprocally for a Scrum Team’s success (e.g. accomplishing a Sprint’s Goal). They are allies with respect to coaching the organization to become, and remain, agile.

A Product Owner is responsible for providing prompt feedback on product matters, clarifying goals, and for ensuring that the entire product delivery team understands the product vision.

A Scrum Master, in return, supports the Product Owner in building a high-value, actionable Product Backlog, and to this end must facilitate effective collaboration between the Product Owner and the Scrum Team.

Question 05: The Product Discovery Process

Should the Scrum Team become involved in the product discovery process and, if so, how?

There are two principal reasons why a Scrum Team should be involved in the product discovery process as early as possible:

The sooner engineers participate in the product discovery process, the lesser the chances solutions will be pursued that are technically not viable or would not result in a return on investment. Involving a Scrum Team early on ensures that the team and its Product Owner develop a shared understanding and ownership of what will be built.

This helps significantly with allocating resources to the right issues, maximizing value for the customer, and mitigating investment risk by maximizing the amount of low-value work not done.

Involving the Development Team members early in the process ensures their buy-in, and the team’s willingness to participate in all phases of a product’s development. This motivates the team to participate when making changes necessary to accomplish the Sprint Goals defined for each Sprint or product release.

Question 06: Supporting the Product Owner

The role of the Product Owner is a bottleneck by design. How do you support the Product Owner so that they maximize value?

This question revisits the previous. Again, your candidate should focus on explaining why involving the Scrum Team early in the product discovery process is beneficial for both the Product Owner and the organization.

Additionally, Scrum Masters can effectively support Product Owners by ensuring that the Product Backlog refinement process is continuous and of a high value regarding the Product Backlog. “Garbage in, garbage out“ does apply to Scrum. Essentially, the Scrum Team either wins together or loses together.

Question 07: Access to Stakeholders

How can you ensure that a Scrum Team has access to a product’s stakeholders?

When answering this question, your candidate should explain that there is no simple way to ensure access to stakeholders.

For example, in larger organizations, functional silos, budgeting and governance practices, and the organizational hierarchies often effectively limit team members’ access to stakeholders. Overcoming this organizational debt, thus building trust among all participants, is a prime objective for the work of Scrum Masters.

Your candidate might suggest encouraging stakeholders to engage in effective (transparent, helpful) communication. Sprint Reviews are a useful venue for this, and the interaction often promotes better relationships between different departments and business units.

Question 08: Stakeholders and the Agile Mindset

How do you promote an agile mindset across departmental boundaries and throughout an organization and, in pursuit of that, what is your strategy when coaching stakeholders not familiar with IT?

There are various tactics a Scrum Master can use to engage stakeholders with Scrum, for example:

Most importantly, a Scrum Master should live and breathe the principles of the Scrum Guide and the Agile Manifesto. They should talk to everyone in the organization involved in building the product, and they should be transparent about what they do. (Read more: 10 Proven Stakeholder Communication Tactics During an Agile Transition.)

Product and engineering teams can produce evidence proving to stakeholders that Scrum is significantly reducing the lead time from idea to product launch.

Product and engineering teams can demonstrate that Scrum mitigates risk (i.e. the forecast of when new features could be made available), thus contributing to other departments’ successes in planning and execution.

A Scrum Team can be transparent with respect to their work and proactively engage stakeholders by inviting them to Sprint Reviews and other events where the team communicates their activity or progress.

Training for everyone in the organization, particularly the stakeholders, is important. One hands-on approach is to organize workshops designed to teach agile techniques for non-technical colleagues.

Question 09: Scrum and Senior Executives

How would you introduce Scrum to senior executives?

This is a deliberately open question meant to encourage discussion. In answering this question, your candidate should elaborate on how they would spread an agile mindset throughout an organization or, ideally, and more specifically, how they would create a learning organization that embraces experimentation in order to identify the best product for its customers.

A good candidate is likely to talk about the necessity of ‘selling’ agile to the organization in order to win the hearts and minds of the stakeholders. They will also point at the necessity to find a high-ranking executive to sponsor the transformation.

At the beginning of a transition any organization shows inertia to change, so to overcome this resistance executives and stakeholders need to know how Scrum will benefit them before they’re likely to make a commitment. (Read more: The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders.)

One practical approach when introducing Scrum to senior executives is to organize workshops for higher management levels. Applying Scrum at the executive level has been successful in the past. Executives, and potentially even key directors, can gain first-hand experience with agile practices if organized as a Scrum Team.

There are no right or wrong answers to this question. Good practices need to take into consideration an organization’s culture, size, product maturity, legal and compliance requirements, and the industry it is operating in.

Question 10: Overcoming Stakeholder Resistance

You’ve already provided your product’s stakeholders with training in Scrum. After the initial phase of trying to apply the concepts, when the very first obstacles are encountered, some of these stakeholders begin to resist continued adoption. What is your strategy for and experience in handling these situations?

This question is meant to encourage an exchange of ideas about, and lessons learned when overcoming resistance to Scrum within an organization. Familiarity with agile failure patterns that are common to many organizations will demonstrate your candidate’s experience. (We have published a list of several agile failure patterns.)

Your candidate should also be familiar with the particular challenge middle managers face in any transition to agile practices. Moving from a command-and-control style (i.e. managing people and telling them what to do) to a servant-leadership style — thus abandoning Taylor’s principles — is not for everyone.

Read more: Why Agile Turns Into Micromanagement.

II. Product Backlog Refinement And Estimation

Question 11: External Requirement Documents

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.

Question 12: PO Anti-Pattern

What kind of information would you require from the Product Owner in order to provide your team with an update on the product and market situation?

Information that a Scrum Master might require from a Product Owner when wanting to update their team on the product, or a market’s reaction to it, would include any information that could provide the Scrum Team with an understanding of why something is of value to customers. Such information may be of a quantitative nature (e.g. analytical data describing how a process is utilized) or of a qualitative nature (e.g. transcripts, screencasts, or videos from a user testing session).

An excellent suggestion on the part of your candidate would be for the Scrum Team to participate in gathering qualitative signals by taking part in user interviews.

Please note: Normally, the Product Owner would provide this information during Sprint Reviews or the refinement process. Noting that the question Q12 itself is pointing at an anti-pattern, that would make a good topic for a Retrospective, is a bonus for the candidate.

Question 13: Writing User Stories

Who should be writing user stories?

Writing user stories should be a joint effort by all members of a Scrum Team—card, conversation, confirmation. If it’s not, the team might not feel that they have ownership of the work items — inevitably leading to less or no commitment, reduced motivation, and ultimately a lower-quality product. Additionally, handing down user stories reduces the accuracy of forecasts by the Development Team members as the joint creation process creates the shared understanding necessary.

Question 14: A Good User Story

What does a good user story look like? What is its structure?

A good user story:

Includes a description,

Has acceptance criteria defined,

Can be delivered within a single Sprint,

Has all UI deliverables available,

Has all (probable) dependencies identified,

Has performance criteria defined,

Has tracking criteria defined, and

Is estimated by the Scrum Team.

Question 15: INVEST

What does the acronym INVEST mean?

The INVEST acronym was coined by Bill Wake and describes the characteristics of a good user story:

Independent. The user story should be self-contained, in a way that there is no inherent dependency on another user story.

Negotiable. Until becoming part of an iteration, user stories can always be changed and rewritten.

Valuable. A user story must deliver value to the end-user.

Estimable. You must always be able to estimate the size of a user story.

Small. User stories should not be so big as to become impossible to plan, task, and prioritize with some certainty.

Testable. The user story (or its related description) must provide the necessary information to make test development possible.

Question 16: Person-hour Estimations

Why aren’t user stories simply estimated in person-hours?

Estimating user stories in person-hours is rarely a good idea. It intentionally diverts the emphasis away from the true purpose of the estimation process: to create a shared understanding of the task ahead among all members of the Scrum Team. Ergo, the estimate itself is just a byproduct.

Estimating is often tricky when:

Legacy software is involved,

A team is facing significant technical debt, or

A team is composed of mostly junior members.

Hence story points are much better suited to estimating than man-hours in all situations, but especially in tricky situations, because they reflect both the complexity of the task and the effort required to complete it.

Using person-hours instead of story points typically shifts the focus from value creation for customers to the more traditional project management of costs and budgeting, effectively imposing a waterfall process. Also, estimating in person-hours suggests an unmerited level of precision.

A good candidate would mention the ongoing discussion in the agile community as to whether estimations are useful in general. They would also likely point to the ‘no estimates’ concept.

Question 17: Cluttering the Product Backlog

The Product Owner of your Scrum Team tends to add ideas of all kinds to the Product Backlog as a reminder to work on them at a later stage. Over time, this has led to over 200 items in various stages. What are your thoughts on this? Can a Scrum Team work on 200 Product Backlog items?

Any Product Backlog larger than the scope of two or three Sprints is barely manageable. Misusing a Product Backlog by adding hundreds of items to it is a clear sign that the Product Owner needs help from the Scrum Team or the Scrum Master to better cope with an influx of ideas, suggestions, and requirements. A smaller Product Backlog avoids misallocating resources; a larger Product Backlog is an indication of waste.

Your candidate should make it clear that they would support a Product Owner in dealing with the size of the Product Backlog, and the ideation process in general, for example, processing input from stakeholders and customers.

III. Sprint Planning

Question 18: A Scrum Master’s Contribution to the Sprint Planning

How can a Scrum Master contribute to Sprint Planning in a way that enables the Scrum Team to work only on the most valuable user stories?

It is the prerogative of the Product Owner to define the business objective of an upcoming Sprint by identifying and ranking the most valuable user stories in the Product Backlog, and it is the duty of the Scrum Master to support the Product Owner in this. Pursuant, a suitable way for a Scrum Master to support a Scrum Team’s strive to work on the most valuable Product Backlog items is:

To ensure that the Scrum Team is involved in the product discovery process at an early stage; To ensure that the Product Backlog refinement process is well practiced by both the Development Team members and the Product Owner; and To ensure that all user stories are created in a collaborative effort between the Product Owner and the Development Team members (the goal being a shared understanding of the user stories and thus joint ownership).

Your candidate should note that although the Product Owner practically outlines the scope of the Sprint, it is the prerogative of the Development Team to address technical debt and bugs during the same Sprint. A Development Team should be able to allocate up to 25% of their available capacity for this. (Read more: Technical Debt & Scrum: Who Is Responsible?)

Question 19: Assessing the Value of a User Story

With what metrics would you assess the value of a user story?

There are quantitative as well as qualitative measurements that may be used to assess the value of a user story or whether the investment is worthwhile. These may include, for example:

Revenue increases,

Cost-cutting benefits achieved by internal process improvements,

Increases in customer satisfaction rates (NPS),

Increases in signups for new products, or

Positive customer feedback received by the customer care team.

Question 20: Selecting the Most Valuable User Stories

How do you facilitate user story selection in a way that the most valuable stories are chosen without overruling the Development Team’s prerogative to select the Sprint Backlog?

If a Development Team is involved early enough in either user story selection (preferably by jointly creating the stories with the Product Owner) or product discovery, a Scrum Master will probably not need to provide any guidance to see that the most valuable stories are chosen.

If a Development Team resorts to cherry-picking — choosing user stories only to satisfy personal preferences — during Sprint Planning, the Product Backlog refinement process needs to be seriously inspected. In all likelihood, the Product Owner is probably focusing on Product Backlog items that are not maximizing customer value.

Question 21: Time Allocation During a Sprint

How much of a Development Team’s capacity during a regular Sprint would you consider adequate for refactoring? Fixing important bugs? Exploring new technologies or ideas?

Apart from Sprints during which there are critical and urgent tasks to address (such as fixing a problem that has taken the web site offline), a good rule of thumb is a 15-10-5 allocation of a Scrum Team’s capacity to refactoring, fixing, and research. Specifically, this means dedicating:

15% of a team’s capacity to technical debt and refactoring,

10% of a team’s capacity to bugs, and

5% of a team’s capacity to explorative spikes (when potentially helpful).

A Development Team may, of course, deviate from this rule of thumb depending on the context. Generally, consistently making these allocations will satisfy both the code quality and maintenance requirements of most software applications and build trust among stakeholders regarding the Scrum Team’s capability to deliver valuable product Increments.

Question 22: Assigning User Stories

Should a Product Owner assign user stories or tasks to individual members of a Development Team?

A Product Owner individually assigning user stories to members of a Development Team is not Scrum, and if a Product Owner is doing this they need to be stopped. Development Teams are self-organizing. The assignment of user stories and the distribution of tasks among the members of a Development Team is the prerogative of the team itself. Preventing this anti-pattern should be one of the Scrum Master’s most pressing concerns.

Question 23: Cherry-Picking Items

How do you deal with team members cherry-picking tasks?

A Development Team has autonomy in how its members choose to distribute tasks, so it may be that a presumed cherry-picking of tasks by individual team members is in fact a valuable and crucial part of the team’s path to performance.

However, if team members are complaining about how others are choosing their tasks, the Scrum Master needs to address the issue. Additional training might help some team members accommodate a greater variety of tasks. Or, perhaps, other team members may need to be gently pushed out of their comfort zone so that they will more readily choose different kinds of tasks over what they’ve become accustomed to. Pair programming may be a suitable first step in that direction.

An anti-pattern of this behavior is when specific tasks, such as quality assurance, are regularly left to the same team members. This pattern reintroduces sub-roles to the Development Team — and needs to be addressed by the Scrum Master.

Question 24: The Almost Ready User Story

A valuable user story is lacking the final user interface designs, but the design team promises to deliver on day two of the upcoming Sprint. The Product Owner for your team is fine with that and pushes to have the user story added to the Sprint Backlog. What are your thoughts on this scenario?

Whether an incomplete user story should be added to the Sprint Backlog depends upon the Development Team’s present concerns and experience with the circumstances. In the case of an incomplete or missing user interface (UI) design, for example, if the design team is almost certain to deliver because they have done so in the past, and if the user story is high value, and if the story can be accomplished within the Sprint despite its UI deliverables arriving late, and if the Development Team agrees to it — then an exception may be acceptable.

Beware that exceptions have a tendency to become accepted practices. An organization’s intent on being agile should not be allowed to bypass the Product Backlog refinement and Sprint Planning process. Your candidate should be aware that such situations are not tenable. Furthermore, if the implementation of a work item subjected to such an exception fails, no one will bother to read the fine print and acknowledge that an exception had been made. Instead, they will most likely view the Scrum process itself as having failed.

Your candidates may either accept or reject exceptions to the process. But they should also be able to analyze situations in which exceptions have been made, and explain the collateral damage that the Scrum Team may be exposed to.

Question 25: Sprint Planning Is a Waste of My Time

A member of the Scrum Team does not want to participate in Sprint Planning and considers the meetings a waste of time. How do you deal with this attitude?

If the member of a Development Team does not want to participate in Sprint Planning and considers the meetings a waste of time, they’re exhibiting a type of passive-aggressive behavior. Although not particular to Scrum, this is a problem because the underlying attitude is toxic and will affect both team-building and team performance as now the knowledge of a team member will not be available at Sprint Planning.

When the member of a Development Team behaves as described, the team’s Scrum Master needs to take action. Counterproductive behavior can neither be ignored nor tolerated if the team is to continue functioning. Effective action is likely to require probably a series of escalating steps:

The Scrum Master may start by addressing the team member privately to discuss their reservations and, perhaps, more coaching needs or a longer training period. Following private discussion, the entire Scrum Team can be involved by making the team member’s reservations a topic of discussion during one or more Sprint Retrospectives. This enables the Scrum Team to offer their support to their teammate. If there is still no change in the team member’s attitude, a meeting with the team member and their line-manager is advisable. If no change can be achieved, it might be possible to reassign the team member to another (probably non-agile) team, or to a Kanban team unlikely to force the team member out of their comfort zone.

Situations such as described highlight how Scrum is not meant for everybody.

Cannot see the form?

Please click here

IV. Daily Scrum

Would you recommend standups for all teams no matter their size or experience level? Do you expect experienced team members to wait until the next standup to ask for help with an impediment? How do you handle team members that “lead” standups, turning them into a reporting session for them? How do you handle team members that consider standups to be a waste of time and therefore are either late, uncooperative or do not attend at all? The standups of your Scrum team are not attended by any stakeholder. How do you change that? How do you approach standups with distributed teams? Can you draw a draft of an offline Kanban board for a Scrum team right now?

V. Sprint Retrospectives

Who shall participate in the retrospective? Do you check the team health in a retrospective or isn’t that necessary? If so, how would you do it? What retrospective formats have you been using in the past? How can you prevent boredom at retrospectives? A team is always picking reasonable action items, but is later not delivering on them. How do you handle this habit? How do you recommend to follow up on actions items?

VI. Agile Metrics

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? What suitable agile metrics have you used in the past? What qualitative agile metrics would you consider tracking?

VII. How to Kick-Off A Transition to Scrum

How would you prepare to kick-off transitioning to Scrum? How would you create the first Scrum team? What do you recommend a newly formed Scrum team works on first?

VIII. Scrum Anti-Patterns

What anti-patterns might a Scrum Master fall into during a sprint? What anti-patterns do you know of that can happen during a retrospective? How can you (as a Scrum Master) identify where you need to improve?

Cannot see the form?

Please click here

How To Use The Scrum Master Interview Questions

Scrum has always been a hands-on business, and to be successful in this, a candidate needs to have a passion for getting her hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas to form and perform as a team, is a complex task. (As always you might say when humans and communication are involved.) And the larger the organization is, the more management level there are, the more likely failure is lurking around the corner.

The 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 in other projects before and the scars to prove it. Last, but not least: Being a “Certified Scrum Master” – or having any other certification of a similar nature – does not guarantee success.

Recommended Reading to Prepare for the Scrum Master Interview

Regarding the general preparation for the Scrum Master job interview, I recommend the following literature on Scrum, Scrum Master, and team building:

Update 2020-06-19: Remote Agile Transitions Challenges

We are used to saying the Scrum is a perfect probe for organizations, as it will reliably discover all dysfunctionalities. Since the pandemic has forced many of us to work remotely, this unique capability has been kicked into overdrive regarding remote agile transitions.

Three months into working with distributed teams, at least for the majority of us who are not working for one of the remote work pioneers like Automatic, Gitlab, or Buffer, operational issues at a tactical level have been addressed. Zoom has fixed many of the problems reported, we learned how to organize engaging remote events, and more people start embracing techniques like Liberating Structures or Training from the Back of the Room to get all sorts of work done. With a good outcome, as it seems that remote work improves productivity, at least when team members are engaged with their work.

Hence I do believe that the Scrum Master candidate needs to have a good understanding of how remote work is accelerating agile transitions and what the primary areas are that are affected.

For an extended list of remote Scrum challenges see Remote Agile Transitions — The Top-Ten Challenges.

Update 2020-04-08: The Scrum Master Interview Enhanced by Remote Scrum with Distributed Teams

How can we learn during the Scrum Master interview whether a candidate has experience with facilitating remote agile events?

To figure out the candidate’s level of competence, I like to run a Liberating Structures-based exercise during the interview. I use TRIZ to task the Scrum Master candidate to come up with suggestions on how to sabotage a remote Scrum approach effectively. These are some of the remote agile anti-patterns, the candidate should be able to identify:

Remote Agile is just standard work-life plus Zoom : Pretending that working remotely is the same as usual except for the video cameras. (This approach ignores all the challenges that distributed team face, for example, not investing enough in getting to know each other better to build trust. We are Social animals and need to meet In person sooner or later to build lasting trust among teammates, thus creating psychological safety. Moreover, there are difficulties in reading the virtual room in general, which means that taking decisions to the team or calling out introverts manifest themselves differently in a remote working setup. Trust is the beginning of all; without it, transparency, inspection, and adaptation would be able to work their magic, and we end up as distributed feature factories.)

: Pretending that working remotely is the same as usual except for the video cameras. (This approach ignores all the challenges that distributed team face, for example, not investing enough in getting to know each other better to build trust. We are Social animals and need to meet In person sooner or later to build lasting trust among teammates, thus creating psychological safety. Moreover, there are difficulties in reading the virtual room in general, which means that taking decisions to the team or calling out introverts manifest themselves differently in a remote working setup. Trust is the beginning of all; without it, transparency, inspection, and adaptation would be able to work their magic, and we end up as distributed feature factories.) Neither fish nor meat : Hybrid events create two classes of teammates — remote and co-located — where the co-located folks are calling the shots. (Beware of the distance bias—when out of sight means out of mind—thus avoiding the creation of a privileged subclass of teammates: “Distance biases have become all too common in today’s globalized world. They emerge in meetings when folks in the room fail to gather input from their remote colleagues, who may be dialing in on a conference line.” (Source.) To avoid this scenario, make sure that once a single participant joins remotely, all other participants “dial in,” too, to level the playing field.

: Hybrid events create two classes of teammates — remote and co-located — where the co-located folks are calling the shots. (Beware of the distance bias—when out of sight means out of mind—thus avoiding the creation of a privileged subclass of teammates: “Distance biases have become all too common in today’s globalized world. They emerge in meetings when folks in the room fail to gather input from their remote colleagues, who may be dialing in on a conference line.” (Source.) To avoid this scenario, make sure that once a single participant joins remotely, all other participants “dial in,” too, to level the playing field. Surveillance : Trust won’t be built by surveilling and micro-managing team members. Therefore, don’t go rogue; the prime directive rules more than ever in a remote agile setup. Trust in people and do not spy on them — no matter how tempting it might be. (Read more about the damaging effect of a downward spiraling trust dynamic from Esther Derby.) https://www.estherderby.com/the-future-may-be-remote-must-it-include-surveillance/

: Trust won’t be built by surveilling and micro-managing team members. Therefore, don’t go rogue; the prime directive rules more than ever in a remote agile setup. Trust in people and do not spy on them — no matter how tempting it might be. (Read more about the damaging effect of a downward spiraling trust dynamic from Esther Derby.) https://www.estherderby.com/the-future-may-be-remote-must-it-include-surveillance/ Mindless rituals : Leadership belief and or facilitation practices turn once useful routines into mindless rituals. (For example, think of Groundhog Day-style retrospectives over and over again. Answering the same three questions every single time is the easiest path to kill any form of creativity and collaboration. While this is hard to avoid in face-to-face environments, it requires much more dedication and energy in a remote agile setting.)

: Leadership belief and or facilitation practices turn once useful routines into mindless rituals. (For example, think of Groundhog Day-style retrospectives over and over again. Answering the same three questions every single time is the easiest path to kill any form of creativity and collaboration. While this is hard to avoid in face-to-face environments, it requires much more dedication and energy in a remote agile setting.) Death by PowerPoint : Meetings still revolve around an individual broadcasting a slide deck. (While you might get away with this approach for some time in face-2-face environments, it will not fly with distributed teams. Sessions need to inclusive, interactive, and engaging to entice collaboration, think Liberating Structures, and Training from the Back of the Room.)

: Meetings still revolve around an individual broadcasting a slide deck. (While you might get away with this approach for some time in face-2-face environments, it will not fly with distributed teams. Sessions need to inclusive, interactive, and engaging to entice collaboration, think Liberating Structures, and Training from the Back of the Room.) Unstructured communication: “Didn’t you get the memo?” (There is no clear practice on how to communicate which kind of information to whom. Are we talking about email, Slack, the team wiki, a comment in Github, or the biweekly remote brow bag session? This lack of structure and agreement leads to stress—how can I avoid missing important news now that there is no longer a watercooler; do I have to monitor all Slack channels in real-time—and probably a feeling of being excluded. Maybe, this effect is just a missing update to the working agreement or team charter. But what if it is done deliberately? (Honi soit qui mal y pense.) in a remote agile environment always requires to overcommunicate and be completely transparent.)

For a comprehensive list of anti-patterns, read Remote Agile (Part 4): Anti-Patterns — Pitfalls Successful Distributed Teams Avoid.

Update 2019-10-12: Have You Already Downloaded Your Copy of the Scrum Master Trends Report?

Have you already dwnloaded your copy of the Scrum Master Trends Report 2019 that we produced in collaboration with Scrum.org, the leading Scrum training and certification institution founded by Scrum co-founder Ken Schwaber?

The Scrum Master Trends Report 2019 is based on a survey of over 2100 participants—both from Scrum.org’s as well as Age-of-Product’s member and subscriber base. The report focuses on trends useful to both new and experienced Scrum Masters and reveals salary trends, agile adoption patterns, while also exploring gender equality within the Scrum Master role. The participants represent 87 different countries and come from all levels of experience. The highlights from the 2019 report include:

81% are using Scrum with other agile practices, ie. Kanban, DevOps, XP.

Scrum Masters with formal Scrum training and agile certifications have higher salaries than those without.

Adoption trends show that 7% are continuing to use Waterfall while 11% are mature in their agile adoption; the remaining participants are early or growing their adoption.

Female salaries are trending higher those of their male counterparts.

Learn more: The Scrum Master Trends Report 2019.

Update 2019-03-27: Watch the Webinar on the Scrum Master Trends Report 2019

Recently, I joined a webinar with Dave West—the CEO and Product Owner of Scrum.org—on the Scrum Master Trends Report 2019. We explored the results including salary trends and agile adoption patterns, addressed gender equality within the Scrum Master role, and answered questions from the audience. The video of the webinar is available now:

Scrum Master Trends Survey Results

Watch this video on YouTube

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar on the Scrum Master Trends Report 2019 directly on Youtube.

Update 2018-11-25: The Webinar Replay ‘Scrum Master Anti-Patterns’ Is now Available

The video of the webinar is available now—you may want to check it prior to your interviews:

Scrum Master Anti-Patterns — (Hands-on Agile Webinar #8)

Watch this video on YouTube

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Scrum Master anti-patterns directly on Youtube.

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