Free Ebook: 83 Scrum Master Interview Questions to Identify Suitable Candidates

TL; DR: The Scrum Master Interview Guide to Identify Genuine Scrum Masters

In this comprehensive Scrum Master Interview guide, we delve into 83 critical questions that can help distinguish genuine Scrum Masters from pretenders during interviews. We designed this selection to evaluate the candidates’ theoretical knowledge, practical experience, and ability to apply general Scrum and “Agile “principles effectively in real-world scenarios—as outlined in the Scrum Guide or the Agile Manifesto. Ideal for hiring managers, HR professionals, and future Scrum teammates, this guide provides a toolkit to ensure that your next Scrum Master hire is truly qualified, enhancing your team’s agility and productivity.

If you are a Scrum Master currently looking for a new position, please check out the “Preparing for Your Scrum Master Interview as a Candidate” section below.

So far, this Scrum Master interview guide has been downloaded more than 25,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 42,000-plus other subscribers.

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

Download the 83 Scrum Master Interview Questions PDF

The free 83 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 of this Scrum Master interview guide will provide more than enough ground for an engaging 60 minute-long conversation with candidates.

Cannot see the form?
Please click here.

Preparing for Your Scrum Master Interview as a Candidate

While this guide has always been intended to help those making hiring decisions, it is also widely spread among Scrum Masters looking for new opprtunities. If you are currently looking for a new job, preparing for a Scrum Master interview in today’s competitive job market requires a strategic and comprehensive approach. Below, you’ll find suggestions to help experienced Scrum Masters not just succeed in their interviews but distinctly stand out:

1. Advanced Scenario Preparation:

• Complex Problem Solving: Describe scenarios where you implemented Scrum in challenging environments, such as teams resistant to agile practices or projects with tight deadlines and budget constraints. For example, use the STAR method — Situation, Task, Action, Result — to provide concrete examples of how your support led to measurable improvements in process and product quality.
• Scalable Solutions: Illustrate your experience “scaling” Scrum practices for larger teams or multiple teams, highlighting your role in addressing integration issues, dependency management, and maintaining alignment between teams to ensure cohesive product development.

2. Demonstrating Continuous Learning and Thought Leadership:

• Advanced Qualifications and Contributions: Discuss your advanced qualifications, such as the PSM III, or contributions to thought leadership (articles, webinars, workshops, Meetups, conferences) that highlight your deep commitment to the agile community.
• Applied Learning: Provide examples of how you’ve applied new learning or trends in agile practices to real-world projects. Discuss your adaptive strategies and innovations in the framework, showcasing your proactive career and skill development approach.

3. Feedback Loops and Team Development:

• Constructive Feedback: Share specific instances where you used constructive feedback to coach or mentor team members, leading to notable improvements in their performance and engagement.
• Retrospectives and Continuous Improvement: Elaborate on how you facilitated effective Retrospectives that led to actionable insights and rapid implementation of improvements, fostering a culture of continuous growth and agility within the team and at personal levels.

4. Proficiency in Tools and Technologies:

• Tool Integration: While the mechanical application of tools is often frowned upon in the community, they are a fact in corporate life. Therefore, be able to detail your experience with integrating and customizing tools like Jira, Confluence, or Asana to fit the specific needs of your teams and projects. Discuss how these tools enhanced project transparency, tracking, and team collaboration, and where they contribution did not justify the effort.
• Metrics and Reporting: Explain how you identified suitable metrics and utilized their data to generate insights, track progress, and make informed decisions that drive project success and align with business goals.

5. Visionary Leadership and Organizational Impact:

• Agile Transformation Initiatives: Discuss your role in broader organizational changes towards agility. Highlight your involvement in training sessions, creating agile advocacy groups, or leading transition initiatives that have significantly shifted the organizational culture and processes towards a more agile mindset.
• Long-term Strategic Contributions: Illustrate how your strategic thinking and agile expertise have contributed to the long-term success of past employers, such as by increasing ROI, reducing time-to-market, and enhancing product quality.

Focusing on these comprehensive and detailed preparation strategies will demonstrate your deep understanding of Scrum and general agile practices and your ability to apply them effectively to drive actual business results, setting you apart from other candidates.

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 accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

Source: Scrum Guide 2020.

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

83 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. During the Scrum Master interview, candidates must demonstrate that understanding.

The role of the Scrum Master, 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 Scrum Master interview guide 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 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.

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

I. Scrum Master Interview Questions: The Role Of The Scrum Master

This set of Scrum Master interview questions focuses on 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 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.”

Question 02: Success Factors of “Agile”

What indicators demonstrate agile practices are working for your organization, and which of these show your efforts are succeeding?

No one can use a standard or general definition of ‘Scrum success’ to measure an organization’s agility. Every organization must develop its own criteria. For example, increasing team velocity is usually not considered a meaningful indicator.

However, although primarily indirect, various indicators may be useful in determining success:

• Products delivered to customers result 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 for pursuing market opportunities successfully, which previously would have been considered futile.
• There has been a reduced allocation of time, money, and brain to low-value products.
• Lead time has been reduced from validated idea to shipped product.
• 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 Scrum 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 necessity 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: 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 collaborate with the 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 Goal). They are allies in coaching the organization to become and remain agile.

A Product Owner is responsible for providing prompt feedback on product matters, clarifying goals, and ensuring that the entire Scrum team understands the product vision, strategy, business model, existing constraints, and customers’ problems.

A Scrum Master, in return, supports the Product Owner in building a high-value, actionable Product Backlog. To this end, they 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:

1. The sooner Developers 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.
2. Involving a Scrum Team early on ensures that the team and its Product Owner develop a shared understanding and ownership of what the Scrum team will build to create customer value.

This helps significantly with allocating efforts to the right issues, maximizing value for the customer. It also helps mitigate investment risk by maximizing the amount of low-value work not done.

Involving the Developers early in the product discovery 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 Sprint Goals or Product Goals.

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 can maximize the value of the work of the Scrum team?

This question revisits the previous. Again, your candidate should focus on explaining why involving the Scrum team early in the product discovery process benefits 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 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 (and Product Owners).

Your candidate should encourage stakeholders to communicate effectively in a transparent, helpful manner. Sprint Reviews are a proper venue for this, and the interaction often promotes better relationships between Scrum teams, 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 agile product development?

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 (for example, in the form of a 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 concerning their work and proactively engage stakeholders by inviting them to Sprint Reviews and other events where the team communicates their activity or progress, but also their need for candid feedback from stakeholders.
• 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 support the creation of an agile mindset throughout an organization or, more specifically, how they would create a learning organization that embraces experimentation to identify the best product for its customers.

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

At the beginning of a transition, any organization shows inertia to change. To overcome this resistance, executives and stakeholders need to know how Scrum will benefit them before they’re likely to commit. (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 is no right or wrong answer 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.

Question 10: Overcoming Stakeholder Resistance

You’ve already provided your product’s stakeholders with training in Scrum. After the initial phase of applying the concepts, when the 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 and lessons learned when overcoming resistance to Scrum within an organization. Familiarity with agile failure patterns common to many organizations will demonstrate your candidate’s experience. (I have published a list of several agile failure patterns.)

Your candidate should also be familiar with the challenge middle managers face in any transition to agile practices. Moving from a command-and-control style (for example, managing people and telling them what to do) to a servant-leadership style — thus abandoning Taylor’s principles — is not for everyone. Concerns of middle managers if they may become redundant when all teams are self-managing need to be acknowledged.

Read more: Why Agile Turns Into Micromanagement.

II. Scrum Master Interview Questions: Product Backlog Refinement And Estimation

This set of Scrum Master interview questions focuses on 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. The Sprint Planning

This set of Scrum Master interview questions focuses on the Sprint Planning:

Question 18: Organization

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.

Question 19: The Feasible Sprint Goal

What factors should a Scrum Team consider at the Sprint Planning to determine a feasible Sprint Goal?

Typical criteria for a Scrum team to consider are, for example:

• Who will be present during the Sprint; is there anyone on holiday or sick leave?
• Are people leaving the team requiring a last-minute knowledge transfer, or do new people joining the team require proper onboarding?
• Will there be public holidays during the Sprint?
• Do we have all the tools necessary, and are we familiar with those?
• Are we familiar with the part of the application we will work on? Or is this terra incognita?
• Are we facing any dependencies on other teams?
• What level of address technical debt do we need to address?
• What was the Scrum team’s past performance?

As any Scrum team plays an infinite game, and there are no winners. Most likely, Stakeholders will regard a Scrum team as successful when it manages to create value for customers and the organization every single Sprint.

Therefore, from a team perspective, building rapport and trust with stakeholders requires more Wallstreet-like expectation management: stakeholders value a reliable delivery more than a sporadic outburst of productivity. This understanding should guide the Scrum team in determining feasible Sprint Goals.

Question 20: Working on Random “Stuff”

Is it acceptable for the Product Owner to introduce a business object for the upcoming Sprint that resembles a list of random work items?

Scrum is at its best when the team can work as a unit to accomplish a single, important goal. As a result, Scrum is good at scoring match points. However, Scrum falls behind when the team has to toil on an endless list of unrelated work items with little to no cohesion.

While such a random list of “stuff” may be an occasional necessity for every Scrum team, the situation should raise eyebrows when it persists. If every Sprint looks like this, the team should reflect on whether Scrum is the proper practice to proceed in general or what it can do to improve its way of working. Here, the interviewer offers the applicant a segway to elaborate on classic Scrum anti-patterns that may contribute to the situation.

Question 21: 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:

1. To ensure that the Scrum Team is involved in the product discovery process at an early stage;
2. To ensure that the Product Backlog refinement process is well practiced by both the Development Team members and the Product Owner; and
3. 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 22: 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 23: Selecting the Most Valuable Work Items

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 24: 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 website 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 25: Assigning Work Items

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 26: 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 27: The ‘Definition of Ready’

Is it okay to use a ‘Definition of Ready?’

Using a ‘Definition of Ready’ depends on the Scrum team’s situation. For example, suppose it is a junior team still struggling with the mechanics of Scrum. In that case, it might be a temporarily helpful way of taking some of the pressure off the team during Product Backlog management, refinement, and Sprint Planning. On the other hand, a senior Scrum team will have found its mojo and won’t need to rely on training wheels.

However, suppose the ‘Definition of Ready’ is used dogmatically as a checklist, rejecting all work items during Sprint Planning that are not 100 percent covered by this new standard. In that case, you are reintroducing waterfall through the backdoor; only the Developers are doing that this time.

Even worse would be the organization’s use of a ‘Definition of Ready’ as a team metric or indicator for a Scrum team’s “fluency” in agile product development.

Question 28: 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 29: 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:

1. 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.
2. 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.
3. If there is still no change in the team member’s attitude, a meeting with the team member and their line-manager is advisable.
4. 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.

Question 30: The Plan of the Developers

Is it a helpful idea for the Developers to plan all work for the whole length of the Sprint during Sprint Planning?

Planning the complete Sprint on day one in advance bears the risk that the Developers do not consider learnings and new insights achieved during the Sprint. Furthermore, this way of proceeding resembles the introduction of some waterfall-style planning through the backdoor, putting the accomplishing of the Sprint Goal unnecessarily at risk by ignoring early feedback loops.

Scrum address this problem with the Daily Scrum that serves one purpose: Are we still on track to accomplish the Sprint Goal? Or have we learned something since the last Daily Scrum that encourages us to reconsider our current plan?

Question 31: Deliveries Matching Forecasts?

Your organization highly values when deliveries match forecasts. Is that something worrisome?

Absolutely. If your organization does not take “underperformance” kindly, everyone will start playing safe. As a result, Scrum teams will routinely choose smaller Sprint Goals and deliver less value than they would be able to do in a more trusting, safe environment.

Question 32: Utilization Rates of Team Members

Should a Scrum Master worry about the utilization rate of the Developers?

Absolutely not. Scrum is not another approach rooted in the industrial paradigm with some “agile lipstick” on top, emphasizing self-management only to micro-manage team members.

Scrum, on the other side, is about accomplishing the Sprint Goal without regard to the output. Here, the Scrum Master is the coach of the team, not the enforcer of “production quotas.” Speaking of which: When solving complex, adaptive problems, focusing on output metrics, such as the utilization rate of your workers, is useless. Adding more code, for example, does not create value per se.

This question provides a segway for the applicant to delve into the general differences between the industrial paradigm and agile product development.

Cannot see the form?
Please click here

IV. Scrum Master Interview Questions: The Daily Scrum

This set of Scrum Master interview questions focuses on the Daily Scrum:

Question 33: The Formal Daily Scrum

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?

Question 34: Impediments

Do you expect experienced team members to wait until the next Daily Scrum in order to ask for help overcoming an impediment?

When impeded, members of a Scrum Team should never need to wait, neither for a Daily Scrum nor any other event, to ask for help. A team waiting to ask for help is a team delaying progress. If the more experienced members of a Scrum Team are waiting for the next Daily Scrum before either asking for help or themselves dealing with an impediment, the Scrum Master has team-building work to do.

Question 35: Leading a Daily Scrum?

How do you handle team members who ‘lead’ Daily Scrums, turning the event into a reporting session for themselves?

There are no leadership roles in the Development Team. However, it’s not uncommon for some members of a Development Team to assume leadership. This typically happens when a particular team member possesses superior (technical) expertise, communication skills, or simply a greater level of engagement.

All teams go through Tuckman’s stages of team development: forming, norming, storming, and performing. Scrum Teams are no exception.

It’s important that when a member of a Development Team assumes leadership this does not result in other members reporting to them. A Scrum Master must be vigilant and intervene if necessary to ensure that all team members communicate and work together — during Daily Scrums and otherwise — in the spirit of Scrum.

Question 36: Waste of My Time?

How do you manage team members who consider Daily Scrums to be a waste of time and are therefore either late, uncooperative, or simply don’t attend?

Refer to Question 25, where addressing this similar attitude and the behavioral problem is discussed at length. Your candidate’s answers should address similar points.

Question 37: Stakeholder Attendance

Your team’s Daily Scrums are not attended by any stakeholder. Should that change?

Asking this question can easily spark a philosophical discussion about whether stakeholders should be allowed to participate in a Development Team’s Daily Scrums. Try to avoid this.

If stakeholders participate in a Development Team’s Daily Scrums, is it likely to result in a form of reporting that circumvents Scrum rules? Not necessarily. It’s good if some adaptation of Scrum can be made to work for an organization. Allowing stakeholders to participate in Daily Scrums need not be ruled out if the Development Team finds it acceptable. In fact, if stakeholders attend Daily Scrums regularly, this invariably and significantly improves communication between a team and their stakeholders.

So shall a Scrum Master encourage stakeholders to attend Daily Scrums? That depends on the context; your candidate should not rule out their participation immediately.

Question 38: Daily Scrum with Distributed Teams

How do you approach Daily Scrums with distributed teams?

Daily Scrums for Development Teams whose members are distributed between different offices or working remotely are not much different from Daily Scrums for Development Teams whose members are co-located. The exception is that distributed teams sharing board activity may require video conferencing when working with offline boards that mirror each other.

If a Scrum Team is using online task management or planning software like JIRA, the team’s boards can be online and updates can take place on-screen. This generally makes it easy for members of a distributed team to follow board activity. With online boards in place, a Zoom or Google Hangouts call will likely be enough for a distributed team to have their Daily Scrum.

Alternatively, the Development Team may try an asynchronous Daily Scrum by utilizing messenger software like Slack. It is the prerogative of the Development Team to decide on the best way of handling their Daily Scrum event.

Question 39: The Scrum Board

Can you draw an example of a Scrum Team’s Kanban board — right now?

In this question, the qualifier ‘Kanban’ is used as a teaser. Anyone interviewing for the role of Scrum Master should be able to draw a simple Sprint board.

The columns of a Sprint board should usually include columns such as:

1. Backlog of tasks,
2. Task In progress,
3. Code review,
4. Quality assurance,
5. Done.

Additional information may be included on or attached to any kind of board:

• Scrum Team members,
• Sprint or event dates,
• Definition of “Done,”
• A burndown chart (progress and work remaining over time),
• A parking lot (topics for future discussion).

Your candidate should mention that a Scrum Master is not obliged to provide the Scrum Team with a Sprint board. A board is the responsibility of the Development Team working with it. The Scrum Master should, however, support the effort with an introductory workshop on the subject if no member of the team is familiar with offline boards.

Read more: How to Build Offline Boards.

V. The Sprint Review

This set of Scrum Master interview questions focuses on the Sprint Review:

Question 40: A Sprint Review without Stakeholders?

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?

This proves to be a controversial question in the Scrum community according to a recent Linkedin poll: Does it make sense to have a Sprint Review when no stakeholders—internal or external—are present?

Votes: 495; comments: 82.

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.

Question 41: Luring Stakeholders to the Sprint Review

What can a Scrum team do to get stakeholders to attend the Sprint Review?

In my experience, you need to “sell” the Sprint Review within the organization, at least at the beginning of using Scrum:

• Help the stakeholders understand the Sprint Review’s importance by educating them properly: Organize workshops, run office hours, etc.
• Provide regular, helpful communication to stakeholders, for example, a newsletter detailing the Scrum team’s work that proceeds the Sprint Review.
• Try and convince higher management to regularly attend the team’s Sprint Reviews. The prospect of having face-time with this individual is often highly motivating for stakeholders to attend, too.
• Choose a stakeholder-friendly calendar slot for the Sprint Review. Scheduling Sprint Reviews on a Monday morning or Friday afternoon is a rookie mistake.
• The same applies to the location of the Sprint Review. Consider in advance how to provide the best experience for a hybrid setting. (In-person and remote attendees.)
• Advertise your Sprint Review; for example, place leaflets in the canteen or cafeteria or communication the date & time in corporate messaging channels or networks. Be creative!

Tackle the problem by addressing it at the next Retrospective and ask for the support of the whole Scrum team to remedy the issue; it is not just something between the Product Owner and the Scrum Master.

Question 42: Passive Stakeholders

Your team’s stakeholders are passive and unengaged at Sprint Reviews. What can the team do to engage with them?

In my experience, that is simple to fix. Some approaches are:

• Why present the outcome to the audience when the stakeholders can explore the Product Increment on their own while the Scrum Team carefully observes what is happening? For example, suppose the stakeholders are thinking loud during the exploration. In that case, it will improve the Scrum Team’s capability to understand whether the Product Increment is meeting expectations and where there is room for improvement.
• Alternatively, organize the Sprint Review as a science fair with several booths where team members introduce solutions to specific problems the Sprint addressed.
• Run an interview with the Product Owner to repeat the upcoming Sprint’s business objective and the long-term goals, thus encouraging reflection on whether the Product Backlog is still up to its task.
• Give away a few small jobs or work items for the next Sprint to stakeholders present at the Sprint Review if they can pitch their ideas successfully to the Developers.

There are plenty of ways to engage stakeholders; be creative. The promising candidate for the Scrum Master position should be able to share some success stories from their past.

Question 43: The Sprint Review as a Stakeholder Approval Gate?

Your Scrum team’s stakeholders attempt to turn the Sprint Review into an approval gate. What might be the reasons for that attitude?

In my experience, the Sprint approval gate anti-pattern is typical for organizations still rooted in the industrial paradigm, exercising command & control. Some of the reasons for this anti-pattern are:

• A “my budget, my feature” attitude on the stakeholder side. The Scrum team is seen as an internal agency, delivering requirements issued by the stakeholders.
• The organization probably follows a metered funding approach, for example, providing a budget for the Scrum team’s development effort only for a short period.
• There is a general lack of trust in a Scrum team’s ability to manage itself successfully: “You need to tell them what to do exactly; otherwise, they come up with things useless to both customers and the organization.”
• Middle managers might even fear becoming obsolete after a successful agile transformation and try to stay their ground by “directing” a self-managing Scrum team.

Generally, the Sprint acceptance gate is a sign of an agile transformation that is not fully supported by all stakeholders.

Question 44: Gold-Plating Beyond Done?

The Developers increased the Sprint’s scope by adding unnecessary effort to Product Backlog items—also referred to as scope-stretching or gold-plating—and surprised the Product Owner at the Sprint Review. What can you do when faced with gold-plating?

My suggestion would be to address the following issues in the next Sprint Retrospective:

• Are Developers and the Product Owner talking often enough with each other; is the Product Backlog refinement process up to the job?
• Are the Developers aware that it is their responsibility to make sound investment decisions when creating Product Increments? Good enough, as in “meets the Definition of Done and the intended purpose,” is a viable approach. It does not always need to be the most elegant, best possible quality solution as long as the Increment delivers the intended value within the existing constraints while contributing to the organization’s viability.
• Do the Developers have a good understanding of costs, from the cost of the Scrum team itself to how money is made to the concept of opportunity costs?
• Do the Developers understand that—except for the technical platform—it is the prerogative of the Product Owner to make these kinds of (investment) decisions?
• How come the Developers violate Scrum Values by disrespecting openness and respect?

Probably, you also want to analyze whether decisions made in the past, for example, the design of extended software architecture, are now driving decisions. So, for example, Developers might be doubling down to underline that a previous decision was correct.

Finally, as we are all humans, brace for the occasional over-excitement on the Developers’ side. Sometimes, a third and brand-new JavaScript framework is simply needed in your application. #sigh

Question 45: Showing Undone Work

The Developers insist on showing undone work to the stakeholders in the name of transparency, defying the spirit of the Scrum Guide. So how would you deal with the situation?

There is a good reason to show unfinished work occasionally. For example, to provide transparency to stakeholders on essential yet challenging tasks. However, regularly showing to Sprint Review attendees on partially finished work violates the concept of “Done,” one of Scrum’s first principles.

My suggestion would be to address the problem in the next Sprint Retrospective, delving into questions like:

Are we facing essential yet challenging technical tasks that may impede the Scrum team’s ability to accomplish the Product Goal that the stakeholders need to understand?

If not, why do the Developers believe it is a valuable exercise to present undone work, thus worsening the signal-to-noise ratio for the stakeholders?

How do we know that stakeholders value this kind of information?

How does this additional information on undone work support our stakeholders’ ability to inspect the Increment and adapt the Product Backlog?

Are there other reasons the Developers need to show their utility to the stakeholders? Is someone questioning them? Do they fear for their jobs?

There are other reasons for the behavior, too. For example, does one of the Developers value pursuing their individual careers over accomplishing the Sprint Goal as a team, positioning themselves for a promotion?

The question should provide ample opportunity for the candidate to delve into the intricacies of practicing Scrum within a larger organization, for example, by sharing similar war stories from their experience.

VI. Scrum Master Interview Questions: The Sprint Retrospectives

This set of Scrum Master interview questions focuses on the Sprint Retrospective:

Question 46: Participants of a Retrospective

Who should participate in a Sprint Retrospective?

Only the immediate members of a Scrum Team — Development Team members, Product Owner, and Scrum Master — should participate in that team’s Sprint Retrospectives.

Especially noteworthy is that the line-managers of a Scrum Team’s members not be present. Also, they should not be allowed access to the minutes of any Sprint Retrospective.

Question 47: Team Health

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

Question 48: Retrospective Formats

What Sprint Retrospective formats have you used in the past?

There are various Sprint Retrospective formats in common use, and each is meant to accommodate different situations. Your candidate should have experience applying more than one of these formats and should be able to share their logic for having done so. Some basic formats for Retrospectives include:

• The classic format:
  • What did we do well?
  • What should we have done better?
• The boat format:
  • What’s pushing us forward?
  • What’s holding us back?
• The starfish Sprint Retrospective:
  • Start doing…
  • Do less of…
  • Do more of…
  • Stop doing…
  • Continue doing…

You can embed all of these formats in the general Sprint Retrospective format popularized by Diana Larsen and Esther Derby:

• Set the stage.
• Gather data.
• Generate insights.
• Decide what to do.
• Close the Sprint Retrospective.

There are several websites available that help Scrum Masters to customize Retrospectives to the needs of the Scrum Team, such as Retromat or Tasty Cupcakes. Alternatively, Liberating Structures provide excellent tools, too.

Suitable candidates will elaborate passionately about their preferred ways and tools for delivering Retrospectives. Candidates that provide only mechanical answers require more scrutiny as the Sprint Retrospective is a key event from a Scrum Master’s perspective.

Question 49: Retrospective Fatigue

How do you prevent boredom during Sprint Retrospectives?

When required to attend an uninspiring Sprint Retrospective, members of a Scrum Team will become bored.

There are many possibilities for variation that can be used to prevent a Sprint Retrospective from being boring, and team members from becoming bored. A different location, a different format, and shortening or lengthening the allotted time box are just some of the variations that can be tried.

Scrum Masters might also use a team’s choice of action items to encourage and structure discussions around issues that matter to the team, thus creating engagement through acknowledgment. Web sites like Retromat offer hundreds of different games and exercises to make Sprint Retrospectives enjoyable and valuable for the whole team.

There is no single solution, and consequently no single correct answer, to either boredom or this question. What’s important is that your candidate acknowledges that boredom with routine might become an issue and that there are ways to deal with it.

Read more: How to Curate Retrospectives for Fun and Profit With Retromat.

Question 50: Not Delivering on Action Items

If your team is picking reasonable action items but not delivering, how would you address the situation?

During a Sprint Retrospective, the members of a Scrum Team would usually pick some action items — tasks to be done — and include them in the upcoming Sprint Backlog. If these action items are subsequently not completed in a timely manner, the Scrum Master needs to follow up.

A team might not be completing the action items they’ve picked because they’ve run into an external impediment. If this is the case, the Scrum Master has to address the cause, and the team can then catch up during a later Sprint.

However, if there is no external impediment, the problem is likely due to motivation, attitude, or personal issues within the Scrum Team. In this latter case, the Scrum Master needs to provide the team members with sufficient encouragement or motivation to overcome the problem — a Scrum Team is self-organizing.

If a team is not completing the action items they’ve picked and the problem ultimately cannot be resolved, picking action items becomes a useless exercise and the Scrum Team’s continuous improvement effort will suffer as a result.

Question 51: Follow-up on Action Items

Would you recommend following up on action items? If so, how would you do that?

The Scrum Team is self-organizing. However, there are always moments when working on improving its practices is less of a Scrum Team’s priority. In this situation, a Scrum Master should follow up on the action items — tasks to be done — that members of a Scrum Team pick during their team’s Sprint Retrospective to remember everyone that Scrum is not working without self-organization.

A good way for a Scrum Master to do this is to start talking about the status of the action items picked during the last Sprint Retrospective before picking new ones by initiating a discussion at the beginning of each new Sprint Retrospective. (Note: This is not meant to be a reporting session but practical help to get self-organization going with the Scrum Team.)

Suppose this discussion uncovers action items picked during a previous Sprint Retrospective that haven’t been completed as expected. In that case, the team needs to understand why this happened and offer its support to prevent it from happening again.

VII. Agile Metrics

This set of the Scrum Master interview questions focuses on agile metrics:

Question 52: 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 53: 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 54: 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.

VIII. Scrum Master Interview Questions: How to Kick-Off A Transition to Scrum

This set of the Scrum Master interview questions focuses on how to kick-off a transition to Scrum:

Question 55: 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 56: 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 57: 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.

IX. Scrum Anti-Patterns

This set of the Scrum Master interview questions focuses on Scrum anti-patterns:

Question 58: 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.
• 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.

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

Question 59: Product Backlog-Related Scrum Anti-Patterns

As a Scrum Master, what are some of the Product Backlog-related Scrum anti-patterns that you need to keep at bay?

Garbage in, garbage out: No matter how well your team is self-managing, how low your level of technical debt is, or how well your team is collaborating with stakeholders in general, your team will be measured primarily by one criterion: can the Scrum team regularly deliver valuable, done Product Increments? The key to live up to that expectation is an actionable Product Backlog which is compact, concise, continuously refined in a team effort, and focussed on delivery of valuable Increments.

According to the Scrum Guide, Scrum Masters support the Product Owner in many ways to ensure this level of Scrum fluency:

• Page 7:The Scrum Master serves the Product Owner in several ways, including helping find techniques for effective Product Goal definition and Product Backlog management.
• Page 7:The Scrum Master serves the Product Owner in several ways, including helping the Scrum Team understand the need for clear and concise Product Backlog items.
• Page 7:The Scrum Master serves the Product Owner in several ways, including helping establish empirical product planning for a complex environment.
• Page 7:The Scrum Master serves the Product Owner in several ways, including facilitating stakeholder collaboration as requested or needed.

Source: Scrum Guide 2020. (The aggregation is taken from the Scrum Guide 2020 Reordered.)

Typical examples of how organizations, Scrum team, or team members fail the principles mentioned above include:

1. Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritizes the Product Backlog. (The strength of Scrum is building on the strong position of the Product Owner. The Product Owner is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on the ordering of the work items. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.)
2. 100% in advance: The Scrum team creates a Product Backlog covering the complete project or product upfront because the scope of the release is limited. (Question: how can you be sure to know today what to deliver in six months from now?)
3. Over-sized: The Product Backlog contains more items than the Scrum team can deliver within three to five Sprints. (This way the Product Owner creates waste by hoarding issues that might never materialize.)
4. Storage for ideas: The Product Owner is using the Product Backlog as a repository of ideas and requirements. (This practice is clogging the Product Backlog, may lead to cognitive overload and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very tough. It also may lead to less collaboration as team members may consider the Product backlog to be ‘complete.’)
5. Copy & paste PO: The Product Owner creates Product Backlog items by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the Product Owner. Remember: Product Backlog item creation is a collaborative team exercise.)
6. What team? The Product Owner is not involving the entire Scrum team in the refinement process and instead is relying on just the “lead engineer” (or any other member of the Scrum team independently of the others).
7. Submissive team: The Developers submissively follow the demands of the Product Owner. (Challenging the Product Owner whether their selection of issues is the best use of the Scrum team’s time is the noblest obligation of every team member: Why shall we do this? Is this the best use of our time from a customer perspective?)
8. No time for refinement: The Scrum team does not have enough refinement sessions, resulting in a low-quality Product Backlog. (The Scrum Guide advises to spend sufficient time on refining the Product Backlog continuously. Which is a sound business decision: Nothing is more expensive than a feature that neither delivers value to customers nor supports the organization’s strive to create a sustainable business.)
9. Too much refinement: The Scrum team has too many refinement sessions, resulting in a too detailed Product Backlog. (Too much refinement isn’t healthy either; you are overinvesting in something potentially wasteful.)

Learn more: 28 Product Backlog and Refinement Anti-Patterns.

Question 60: Sprint Planning-Related Scrum Anti-Patterns

As a Scrum Master, what are some of the Sprint Planning-related anti-patterns that you need to avoid as a team?

According to the Scrum Guide, the Sprint Planning plays a vital role in the value creation process of the Scrum team:

• Page 8: Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.
• Page 8: This resulting plan is created by the collaborative work of the entire Scrum Team.
• Page 8: The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.
• Page 8: [Sprint Planning: Why is this Sprint valuable?] The Product Owner proposes how the product could increase its value and utility in the current Sprint.
• Page 8: [Sprint Planning: Why is this Sprint valuable?] The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
• Page 8: [Sprint Planning: Why is this Sprint valuable?] The Sprint Goal must be finalized prior to the end of Sprint Planning.

Source: Scrum Guide 2020. (The aggregation is taken from the Scrum Guide 2020 Reordered.)

Therefore, it should be of the highest priority of any Scrum team to perform the best possible Sprint Planning. It is the last moment where the Scrum team can change direction; once the Sprint Goal is defined, the investment decision is made. In my experience, the following six Sprint Planning anti-patterns have the most negative impact on a Scrum team’s value creation:

• What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision. (A serious business objective answers the “What are we fighting for?” question. A good goal derived from this alignment is focused and measurable, as the goal of the upcoming Sprint — based on the business objective — and Developers’ forecast goes hand in hand.)
• No business objective, no Sprint Goal: The Product Owner proposes Product Backlog items that resemble a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint Goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of ordering the Product Backlog appropriately.)
• Unfinished business: Unfinished work items from the last Sprint spill over into the new Sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though, remember the sunk cost fallacy.)
• Last-minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that are not ready yet. (Principally, it is the prerogative of the Product Owner to make such kind of changes to ensure that the Developers are working only on the most valuable tasks at any given time. However, if the Scrum Team is otherwise practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the Product Owner needs help with ordering the Product Backlog and team communication. Or the Product Owner needs support to say ‘no’ more often to stakeholders.)
• Output focus: The Product Owner pushes the Developers to take on more tasks than it could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It is violating the Developers’ prerogative to pick Product Backlog item for the Sprint Backlog as well as Scrum Values.)
• No preparation: The Product Owner does not prepare the Product Backlog to provide useful Product Backlog items for selection by the Development Team. (Product Backlog needs to represent the best possible use of the Developers’ work from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, that means that you need to be capable of running a meaningful Sprint Planning instantly. Preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.)

Question 61: Sprint Review-Related Scrum Anti-Patterns

As a Scrum Master, what are some of the Sprint Review-related anti-patterns that you need to avoid as a team?

According to the Scrum Guide, the Sprint Review is an essential moment of collaboration with internal and external stakeholders to reassure that the Scrum team is still on the right track:

• Page 9: The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
• Page 9: The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
• Page 9: During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.
• Page 9: The Product Backlog may also be adjusted to meet new opportunities.
• Page 9: The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Source: Scrum Guide 2020. (The aggregation is taken from the Scrum Guide 2020 Reordered.)

Some of the most damaging Sprint-Review anti-patterns in my experience are as follows:

• Following a plan: The Scrum Team does not use the Sprint Review to discuss the current state of the product or project with the stakeholders. (Again, creating transparency and receiving feedback is the purpose of the exercise. A we-know-what-to-build attitude is bordering on hubris. Read More: Sprint Review, a Feedback Gathering Event: 17 Questions and 8 Techniques.)
• Death by PowerPoint: Participants are bored to death by PowerPoint. (The foundation of a successful Sprint Review is “show, don’t tell,” or even better: let the stakeholders drive the discovery.)
• Sprint accounting: Every task accomplished is demoed, and stakeholders do not take it enthusiastically. (My suggestion: Tell a compelling story at the beginning of the review to engage the stakeholders. Leave out those user stories that are probably not relevant to the story. Do not bore stakeholders by including everything that was accomplished. We are not accountants; the output is less relevant by comparison to the outcome from a customer or value creation perspective.)
• Cheating: The Development Team shows items that are not “done.” (There is a good reason to show unfinished work on some occasions. Partially finished work, however, violates the concept of “Done,” one of Scrum’s first principles.)
• Scrum à la Stage-Gate®: The Sprint Review is a kind of Stage-Gate® approval process where stakeholders sign off features. (This Sprint Review anti-pattern is typical for organizations that use an “agile”-waterfall hybrid. However, it is the prerogative of the Scrum team to decide what to ship when.)
• No stakeholders: Stakeholders do not attend the Sprint Review. (There are several reasons why stakeholders do not participate in the Sprint Review: they do not see any value in the event, or it is conflicting with another important meeting. They do not understand the importance of the Sprint Review event. No sponsor is participating in the Sprint Review, for example, from the C-level. To my experience, you need to “sell” the event within the organization, at least in the beginning of using Scrum.)
• No customers: External stakeholders—also known as customers—do not attend the Sprint Review. (Break out of your organization’s echo chamber, and invite some paying users to your Sprint Review. Everyone will be grateful for that.)
• Side gigs: The Development Team was working on issues outside the Sprint Goal, and the Product Owner learns about those for the first time during the Sprint Review. (For the sake of transparency, openness, and respect: There is no room for side gigs when using Scrum.)

Learn more: 15 Sprint Review Anti-Patterns Holding Back Scrum Teams.

Question 62: 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 63: 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.

X. Scrum Master Interview Questions: Scrum Success Principles and Indicators

This set of the Scrum Master interview questions focuses on Scrum success principles and indicators:

Question 64: When to Use Scrum and what to Look for

Can we use Scrum to solve any problem, task, or challenge? Or do you think that Kanban or even Waterfall may be better solutions in some cases? Moreover, if we choose Scrum, what principles and success indicators shall we observe?

Scrum is not the Swiss Army knife for any problem a product team may be facing. Throwing Scrum at all problems indiscriminately will likely be an ineffective strategy. However, when Scrum is chosen for the proper purpose, four first principles support Scrum Masters to help their teams deliver:

Choose Scrum for the Right Purpose:

Choosing the appropriate application area for Scrum is essential. Referring to the Stacey Matrix, applying Scrum to the areas “Chaos” and “Simple” is a waste. Scrum is best used in the “Complex” area. Here, empirical process control thrives, applying transparency, inspection, and adaptation to iteratively, incrementally developing valuable product Increments, thus mitigating risk.

Strive for High Product Quality:

From day one, keep technical debt small and work continuously on high product quality, reflected in the Scrum Team’s Definition of Done. Achieving business agility requires dedication to product quality and excellence at the technical level. (Learn more: Technical Debt & Scrum: Who Is Responsible?

Create and Maintain an Actionable Product Backlog:

Garbage in, garbage out: No matter how your Scrum Team is everything else, a sub-standard Product Backlog will diminish all other team achievements. Hence, it would be best to support the Product Owner and the Developers to maintain a permanently “actionable” Product Backlog. By “actionable,” I am referring to a refinement level of the Product Backlog that would allow a Scrum Team to run a meaningful Sprint Planning at a moment’s notice. (Learn more: 28 Product Backlog and Refinement Anti-Patterns.)

Embrace Self-Management and Take It to the Scrum Team:

Restrain from solving problems that your teammates can solve themselves. I know it feels good to be helpful; however, it is not your job as a Scrum Master to become the team’s helping hand in all matters. Instead, make self-management our number one priority and ensure that everyone lives Scrum Values. Be a servant-leader at heart and, therefore, a good role model for the Scrum team.

Note: All sketches are taken from a previous Professional Scrum Master class; check out my upcoming training classes here.

Question 65: Scrum Master Success

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.

Question 66: Scrum Product Owner Success

How could you measure the success of a Product Owner?

There are several indicators of the success of a Product Owner, for example:

• The Scrum team regularly meets Sprint Goals and delivers valuable, done Increments, see above.
• The successful Product Owner aligns stakeholders and team member regarding product vision and Product Goal.
• They are obsessed with creating value for the customers while creating a sustainable business for the organization.
• Successful Product Owners are data-informed, not data-driven. Progress is made through applying empiricism.
• They include the Developers in the product discovery process early.
• Product Owners expect to be challenged by the Developers during Product Backlog refinement regarding their choices.
• They are transparent and outstanding communicators.

Question 67: Scrum Developer Success

How could you measure the success of the Scrum Developers?

There are several indicators of the success of Developers on a Scrum Team, for example:

• The Scrum team regularly meets Sprint Goals and delivers valuable, done Increments; again, see above.
• Developers actively engage in self-managing during the Sprint to meet the Sprint Goal.
• They take control over the Sprint Backlog.
• Developers accept the collective responsibility for quality.
• They uphold product quality by regularly inspecting the Definition of Done in collaboration with the Product Owner.
• Developers keep technical debt at bay by allocating sufficient time to refactoring and bug-fixing every Sprint.
• They take their commitment to continuous improvement as a team seriously by acting on actions items from Retrospectives.
• Successful Developers have a collaborative mindset; for example, they share knowledge, pair program, or swarm to support other Developers accomplishing their tasks.
• They identify gaps in their knowledge or experience and reach out to others to help fill them.

XI. How to Make Your Scrum Master Fail

This set of the Scrum Master interview questions focuses on how to make your Scrum Master fail at an organizational level:

Here is the briefing for the candidate that applies to all of the following six questions:

You are a middle manager in the IT organization, and you believe this Scrum thingy is a fad and will go away—with a little help from your side.

Come up with ideas on how to best sabotage the new Scrum Master of the first Scrum Team in your organization. You’re not allowed to use any form of illegal activity. So, outsourcing the task to a bunch of outlaws is out of the question. Instead, you are only allowed to use practices that are culturally acceptable within your organization.

Please find following questions from the “How to Make Your Scrum Master Fail” chapter to identify suitable candidates for the role of Scrum Master or agile coach:

Question 68: How To Mess with the Scrum Framework in General

How can you mess with the Scrum framework itself?

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.

Question 69: Employing Unsuitable Metrics & Reporting

How can you use excessive reporting requirements or unsuited metrics to pursue your agenda?

The next bucket of useful sabotage practices are metrics, OKRs, KPIs — you name it. Just turn your Scrum Master into a glorified data-entry clerk with a challenging reporting burden. Successful approaches are:

• Ask the Scrum Master to prove their value with metrics.
• Create performance KPIs for each team member.
• Ask the Scrum Master to collect all working hours of the team members.
• Ask for individual performance metrics for every Sprint.
• Tie team member performance reviews with their average story points per Sprint using the Bell curve.
• Calculate a Scrum team budget and insist that the utilization rate of team members needs to be higher.
• Demand estimates and treat them as commitments.

Question 70: Messing with Scrum Team Building & Line Management

How can you interfere with the team building by utilizing your line management prerogatives?

If a challenging reporting burden does not help, sabotage your Scrum Master by actively undermining their activities to turn a group of people into a cross-functional Scrum Team. Examples to consider are:

• Only add members to the Scrum team that don’t live any Scrum values.
• Recommend the most bull-headed senior developer as the engineering team lead.
• Constantly switch Developers from one project to another, claiming emergencies that require swift action.
• Have Scrum team members regularly work on multiple different Scrum teams.
• Add in new people to the Scrum team without prior consultation.
• Alternatively, slow down the hiring or replacement processes.
• Promote a member within the Scrum team to act as a proxy manager.

Question 71: Interfere with Work Organization

How can impede the Scrum team’s self-management and work organization?

If you are already messing with the Scrum Team team-building process, why not place a few obstacles into the Scrum Team’s way of working? Sabotage your Scrum Master by creating unachievable objectives while meddling with the very foundation of Scrum:

• Define unachievable objectives for the Scrum Team.
• Overload the Scrum team with requests, then complain to others that you do not get results on time.
• Hand over only fixed price, time, and scope projects to Scrum Team.
• Change requirements during the Sprint.
• Insist on hard deadlines.
• Ask the Scrum Master to provide a product roadmap with deadlines.
• Make the Scrum Master responsible for accomplishing deadlines.
• Outsource part of the product roadmap creation to an off-site team in a completely different timezone.
• Request work that would switch focus away from the Sprint Goal directly to Developers.
• Assign tasks directly to Scrum team members.
• Don’t allow Scrum Team members to speak to the customer; act as the single point of contact.
• Create unnecessary organizational bottlenecks outside of Scrum, for example, approvals gates, etc.
• Only provide inadequate equipment and tools to the Scrum team.

Question 72: Manipulating the Flow of Information

How can you manipulate the flow of information to the Scrum team?

Does your Scrum Master have an insatiable appetite for data, information, and knowledge? Well, keep them out of the loop then. What could be an easier way of sabotaging Scrum:

• Claim that everyone already knows what to do. There is hence a need for alignment or a Scrum Master.
• Restrain from sharing essential or valuable information with the Scrum Team.
• Encourage silo thinking by promoting a strict “need to know” basis for sharing information and knowledge.

Question 73: Use other Meetings to Interfere with Scrum Events

How can you use other events and meetings to make planning and communication harder for the Scrum team?

Finally, ensure that everyone on the Scrum Team understands that your events are more important than theirs:

• As a manager, claim that there are too many Scrum events that require too much time. Instead, suggest skipping some of them.
• Require to be present at every Scrum event.
• Exclude Scrum Master from important meetings outside the Scrum Team’s events.
• Constantly pull Scrum team members into long unnecessary meetings during their Scrum team events.
• Be very understanding of the needs of the Scrum Team; for example, that stakeholders shall participate in the Sprint Review. However, never join any Scrum event yourself.

XII. Creating Value as a Scrum Master

The following questions and responses are designed to draw out a nuanced understanding of a candidate’s experience and skills in applying agile product development principles to improve customer value and economics of delivery and enhance predictability in various organizational contexts to address the current economic climate:

Question 74: Resistant Industries

How have you tailored Scrum practices to elevate customer value, particularly in industries resistant to Agile practices?

Background: This question probes the candidate’s ability to adapt Scrum principles to sectors where Agile is not the norm, emphasizing customer-centric product development. It seeks insights into the candidate’s innovative application of Scrum to foster customer engagement and satisfaction, even in challenging environments. It is also an opportunity for the candidate to build confidence in the interview process and rapport with the interviewers.

Acceptable Answer: An excellent response would detail a scenario where the candidate navigated resistance by demonstrating Agile’s benefits through small-scale pilot projects or workshops. They would probably even describe specific adjustments to Scrum events or artifacts to align with industry-specific constraints, culminating in enhanced customer feedback loops and ultimately leading to product features that directly addressed customer pain points.

Question 75: Reducing Product Costs

Please describe a scenario in which you significantly reduced production costs through strategic Scrum application without compromising the product’s quality.

Background: This delves into the candidate’s proficiency in supporting the optimization of a team’s capacity allocation and streamlining workflows within the Scrum framework to cut costs. It’s about balancing maintaining high-quality standards and achieving cost effectiveness through Agile practices.

Acceptable Answer: Look for a narrative where the candidate identifies wasteful practices or bottlenecks in the development process and implements targeted Scrum practices to address them. Examples include refining the Product Backlog to focus on high-impact features, improving cross-functional collaboration to reduce dependencies, or leveraging automated testing to speed up lead time while preserving quality standards. The answer should highlight the candidate’s analytical problem-solving approach and ability to help the team accept a cost-conscious entrepreneurial stance to solving customer problems without sacrificing quality.

Question 76: Improving Predictability in a Volatile Market

Please share an experience where you used Scrum to improve predictability in product delivery in a highly volatile market.

Background: This question explores the candidate’s capability to use Scrum to enhance delivery predictability amidst market fluctuations. It’s about leveraging Agile’s flexibility to adapt to changing priorities while maintaining a steady pace of delivery.

Acceptable Answer: The candidate should recount an instance where they utilized Scrum artifacts and events to better forecast delivery timelines in a shifting landscape. This example might involve adjusting Sprint lengths, prioritizing Product Backlog items more dynamically, or involving closer stakeholder engagement to reassess priorities during Sprint Reviews or other alignment-creating opportunities, for example, User Story Mapping sessions. The story should underscore their strategic thinking in balancing flexibility with predictability and their communication skills in setting realistic expectations with stakeholders.

Question 77: Successfully Promoting Scrum Despite Skepticism

How have you promoted the value of Scrum in organizations where the leadership and middle management met Agile practices with skepticism?

Background: This question examines the candidate’s ability to champion Scrum in environments resistant to change. Such an environment requires a deep understanding of Agile principles and strong advocacy and education skills.

Acceptable Answer: Successful candidates will describe a multifaceted strategy that includes educating leadership on Agile benefits, organizing interactive workshops to demystify Scrum practices, and securing quick wins to demonstrate value. They might also discuss establishing a community of practice to sustain Agile learning and sharing success stories to build momentum. The answer should reflect their perseverance, persuasive communication, and their role as a change agent. (Learn more about successful stakeholder communication tactics during transformations here.)

Question 78: Effective Change

Please describe your approach to conducting effective Sprint Retrospectives that drive continuous improvement.

Background: The question probes the candidate’s techniques for facilitating Retrospectives that genuinely contribute to team growth and product enhancement. It seeks to understand how they ensure these events are productive, inclusive, and actionable.

Acceptable Answer: A comprehensive response would outline a structured approach to Retrospectives, including preparation, facilitation, follow-up practices, and valuable enhancements to the framework, for example, embracing the idea of a directly responsible individual to drive change the team considers beneficial. The candidate might mention using a variety of formats to keep the sessions engaging, techniques to ensure all team members contribute, and strategies for prioritizing action items. They should emphasize their method for tracking improvements over time to ensure accountability and demonstrate the Retrospective’s impact on the team’s performance and morale. Again, this question allows the candidates to distinguish themselves in the core competence of any Scrum Master.

Question 79: Balancing Demands with Principles

Please explain how you’ve balanced stakeholder demands with Agile principles to help the Scrum team prioritize work effectively.

Background: This question seeks insights into the candidate’s ability to support the Scrum team in general and the Product Owner in particular in navigating competing demands, aligning stakeholder expectations with Agile principles to focus the team’s efforts on the most impactful work from the customers’ perception and the organization’s perspective.

Acceptable Answer: The candidate should provide an example of supporting the Product Owner by employing prioritization techniques, such as User Story Mapping, in collaboration with stakeholders to align on priorities that offer the most value, leading to the creation of valuable Product Goals and roadmaps in the process. They should highlight their negotiation skills, ability to facilitate consensus, and adeptness at transparent communication to manage expectations and maintain a sustainable pace for the team.

Question 80: Boring Projects and Motivation

How do you sustain team motivation and engagement in long-term projects with high levels of task repetition?

Background: This question explores the candidate’s strategies for keeping the team engaged and motivated through the monotony of prolonged projects or repetitive tasks. While we all like to work on cutting-edge technology all the time, everyday operations often comprise work that we consider less glamorous yet grudgingly accept as valuable, too. The question gauges a candidate’s ability to uphold enthusiasm and maintain high performance in a potentially less motivating environment.

Acceptable Answer: Expect the candidate to discuss innovative approaches like introducing gamification elements to mundane tasks, rotating roles within the team to provide fresh challenges, and setting up regular skill-enhancement workshops. They might also mention the importance of celebrating small wins, giving recognition, for example, Kudo cards, and ensuring that the team’s work aligns with individual growth goals. The response should underline their commitment to maintaining a positive and stimulating work environment, even under challenging circumstances.

Question 81: Onboarding New Team Members

Please describe your experience integrating a new team member into an established Scrum team, ensuring a seamless transition and maintaining team productivity.

Background: This question assesses the candidate’s approach to onboarding new team members to minimize disruption and maximize integration speed. This approach is critical for maintaining an existing team’s cohesive and productive dynamics, acknowledging that Scrum teams will regularly change composition.

Acceptable Answer: Look for answers detailing a structured and inclusive onboarding plan that includes, for example, mentorship programs, a buddy system, clear documentation of team norms and expectations, such as a working agreement and a Definition of Done, team activities, and gradual immersion into the Scrum team’s projects through pair programming or shadowing. The candidate should highlight the importance of fostering an inclusive team culture that welcomes questions and supports new members in their learning journey, ensuring they feel valued and part of the team from day one.

Question 82: Conflict Resolution

How do you approach conflict resolution within a Scrum team or between the team and stakeholders to ensure continued progress and collaboration?

Background: Conflicts are inevitable in any team dynamic. This question probes the candidate’s skills in navigating and resolving disagreements in a way that strengthens the team and stakeholder relationships rather than undermining them.

Acceptable Answer: The candidate should describe their ability to act as a neutral mediator, actively listen to understand all perspectives, and facilitate problem-solving sessions focusing on interests rather than positions. They might also discuss creating forums for open dialogue, such as conflict-themed Retrospectives, and the importance of fostering a culture of trust and psychological safety where conflicts can be aired constructively. The response should convey their adeptness at turning conflicts into opportunities for growth and deeper understanding. However, the candidate should also make clear that not all disputes among team members may be solvable and that, once all team-based options have been exhausted, the Scrum Master needs to ask for management support to bring the conflict to a conclusion.

Question 83: Scaling Scrum?

Please reflect on a time when scaling Scrum across multiple teams presented significant challenges. How did you address these challenges to ensure the organization’s success with its Agile transformation?

Background: Scaling Agile practices is a complex endeavor that can highlight organizational impediments and resistance. This question delves into the candidate’s experience in successfully scaling Scrum, ensuring alignment and cohesion among multiple teams, and helping everyone see the value in a transformation.

Acceptable Answer: This open question allows candidates to address their familiarity with frameworks like LeSS or Nexus or share their opinion on whether SAFe is useful. Moreover, at a philosophical level, it opens the discussion of whether “Agile” is scalable at all, given that most scaling frameworks apply more processes to the issue. Also, the objecting opinion points to the need to descale the organization by empowering those closest to the problems to decide within the given constraints and governance rules. The candidate should emphasize the importance of maintaining a shared vision and goals, creating communities of practice to share knowledge and best practices, and addressing cultural barriers to change. They should also reflect on the importance of executive sponsorship and the strategic engagement of key stakeholders to champion and support the scaling effort.

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 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 in other projects before and the scars to prove it.

Conclusion

Selecting the right Scrum Master is crucial for the success of your Scrum teams and, thus, your organization’s goal of achieving business agility. With the questions outlined in this article, you can probe the depth of a candidate’s understanding and their practical capabilities in agile practices in general and Scrum in particular. Remember, a great Scrum Master is living and breathing the principles embodied in the Scrum Guide and the Agile Manifesto in their everyday actions and decisions. Use these questions to uncover candidates who can genuinely drive agile transformations and contribute to your organization’s continuous improvement culture while solving your customers’ problems sustainably within the given constraints.

Recommended Reading to Prepare for the Scrum Master Interview

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

• The Scrum Guide
• The Nexus Guide
• The Manifesto for Agile Software Development
• Gunther Verheyen: Scrum — A Pocket Guide (Amazon advertisement.)
• Geoff Watts: Scrum Mastery (Amazon advertisement.)
• Stanley McChrystal: Team of Teams (Amazon advertisement.)
• Patrick Lencioni: The Five Dysfunctions of a Team (Amazon advertisement.)

Scrum Master Interview Questions: Revision History

Update 2024-06-23: Preparing for Your Scrum Master Interview

I extended the Scrum Master interview guide with a new section on how to best prepare for the initial Scrum Master job interview and stand out.

Update 2024-04-07: Creating Value with Scrum

I extended the Scrum Master interview guide with ten questions addressing value creation with Scrum; please see Set XII.

Update 2022-10-16: The Sprint Planning

I extended the Scrum Master interview guide with seven questions addressing the Sprint Planning; please see Set III.

Update 2022-06-18: The Sprint Review

I extended the Scrum Master interview guide with six questions addressing the Sprint Review; please see Set V.

Update 2022-01-07: How to Make Your Scrum Master Fail

Any Scrum Master interview a challenging task. A good starting point, though, is to ask a candidate to walk in the shoes of an imaginary opponent trying to make the Scrum Master fail by culturally accepted means.

Update 2021-09-12: More Questions on Scrum Anti-Patterns

I added three new questions on Scrum anti-patterns, from the Product Backlog to the Sprint Planning to the Sprint Review to the Scrum Master interview guide, providing more insight into the Scrum value creation process and the organization’s return on investment.

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.

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. Moreover, that understanding shall show during the Scrum Master interview.

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

Update 2020-04-08: The Scrum Master Interview Guide 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.)
• 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.
• 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.)
• 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.)
• 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 downloaded 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 than those of their male counterparts.

Learn more: The Scrum Master Trends Report 2019.

Update 2021-07-11: Four new questions added (Section X)

I added four new questions on Scrum success principles and indicators to the Scrum Master interview guide, ranging from when to use Scrum, Scrum first principles, to signs of successful Scrum Masters, Product Owners, and Developers.

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:

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 Scrum Master interview:

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.

📖 Scrum Master Interview Questions: Recommended Articles

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

Getting Hired as a Scrum Master or Agile Coach

The Scrum Master Salary Report 2024

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

Download the ’82 Scrum Product Owner Interview Questions to Avoid Agile Imposters’ ebook for free

Download the ’Scrum Anti-Patterns Guide’ for Free

📅 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 Scrum Master Interview Questions — Join the 19,000-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you would like to join 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.

Prepare yourself for the Scrum Master interview by studying the free Scrum Anti-Patterns Guide: