Scrum Master Interview Questions (6): Scrum Anti-Patterns

TL; DR: Scrum Master Interview Questions (6): Scrum Anti-Patterns

Scrum has proven time and again to be the most popular framework for software development. Given that software is eating the world, a seasoned Scrum Master is nowadays in high demand. And that demand causes the market-entry of new professionals from other project management branches, probably believing that reading one or two Scrum books will be sufficient. Which makes any Scrum Master interview a challenging task.

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

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

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

Scrum Master Interview Questions: How We Organized Questions and Answers

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

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

Please find following questions from the “Scrum Anti-Patterns Chapter” to identify suitable candidates for the role of Scrum Master or agile coach.

Cannot see the form?
Please click here

Scrum Anti-Patterns: From Product Backlog to Sprint Review

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

Question 45: Scrum Master Anti-Patterns

What anti-patterns might a Scrum Master fall into during a Sprint?

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

• Keeping the Scrum team dependent: In this scenario, the Scrum Master pampers the team to a level that keeps the team dependent on his or her services: organizing meetings, purchasing stickies and sharpies, taking notes, updating Jira—you get the idea of this service level. More critical, however, is when the Scrum Master decides to keep the team in the dark about principles and practices to secure his or her job. This behavior is only a small step away from the dark side.
• Flow disruption: The Scrum Master allows stakeholders to disrupt the workflow of the Development Team during the Sprint. There are several possibilities on how stakeholders can interrupt the flow of the team during a Sprint:
  • The Scrum Master has a laissez-faire policy regarding access to the Development Team.
  • The Scrum Master does not object when management invites engineers to random meetings as subject matter experts.
  • Lastly, the Scrum Master allows either the stakeholders or managers to turn the daily Scrum into a reporting session.
• Lack of support: The Scrum Master does not support team members who need help with a task. Development teams often create tasks an engineer can finish within a day. However, if someone struggles with a task for more than two days without voicing that they need support, the Scrum Master should address the issue. Importantly, this is also the reason for marking tasks on a physical board with red dots each day if they haven’t been moved on to the next column.
• Turning a blind eye to micromanagement: The Scrum Master does not prevent the Product Owner – or anyone else – from assigning tasks to engineers. The Development Team normally organizes itself without external intervention. And the Scrum Master should act as the shield of the team in this respect.
• 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 46: 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 47: 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 48: 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 49: 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 50: 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.

How To Use The Scrum Master Interview Questions

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

The questions are not necessarily suited to turn an inexperienced interviewer into an agile expert. But in the hands of a seasoned practitioner, they support figuring out, what candidate has been working the agile trenches in the past.

Scrum Master Interview Questions — Recommended Reading

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

Download the ’Scrum Anti-Patterns Guide’ for Free

The Scrum Master Trends Report 2019

22 Scrum Master Anti-Patterns from Job Ads

23 Product Owner Anti-Patterns from Job Ads: The Snitch, the Whip, the Bookkeeper, the Six Sigma Black Belt™

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