Scrum Master Interview Questions (2): From Product Backlog to Sprint Planning

TL; DR: Demand Creates Supply and the Job Market for Scrum Masters Is no Exception

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

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

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

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

📅 Join us for a free virtual Barcamp on October 1, 2020 — we will test a promising new virtual event platform.

Scrum Master Interview Questions: How We Organized Questions and Answers

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

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

Please find following the latest subset from the 47 Scrum Master interview questions to identify suitable candidates for the role of Scrum Master or agile coach: Product Backlog, refinement, and the Sprint Planning.

II. Product Backlog Refinement And Estimation

Question 11: External Requirement Documents

The Product Owner for your Scrum Team frequently turns requirements documents received from stakeholders into tickets and asks you to estimate each. How do you feel about this procedure?

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

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

Question 12: PO Anti-Pattern

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

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

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

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

Question 13: Writing User Stories

Who should be writing user stories?

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

Question 14: A Good User Story

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

A good user story:

• Includes a description,
• Has acceptance criteria defined,
• Can be delivered within a single Sprint,
• Has all UI deliverables available,
• Has all (probable) dependencies identified,
• Has performance criteria defined,
• Has tracking criteria defined, and
• Is estimated by the Scrum Team.

Question 15: INVEST

What does the acronym INVEST mean?

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

• Independent. The user story should be self-contained, in a way that there is no inherent dependency on another user story.
• Negotiable. Until becoming part of an iteration, user stories can always be changed and rewritten.
• Valuable. A user story must deliver value to the end-user.
• Estimable. You must always be able to estimate the size of a user story.
• Small. User stories should not be so big as to become impossible to plan, task, and prioritize with some certainty.
• Testable. The user story (or its related description) must provide the necessary information to make test development possible.

Question 16: Person-hour Estimations

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

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

Estimating is often tricky when:

• Legacy software is involved,
• A team is facing significant technical debt, or
• A team is composed of mostly junior members.

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

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

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

Question 17: Cluttering the Product Backlog

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

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

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

III. Sprint Planning

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

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

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

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 19: Assessing the Value of a User Story

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

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

• Revenue increases,
• Cost cutting benefits achieved by internal process improvements,
• Increases in customer satisfaction rates (NPS),
• Increases in signups for new products, or
• Positive customer feedback received by the customer care team.

Question 20: Selecting the Most Valuable User Stories

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

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

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

Question 21: Time Allocation During a Sprint

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

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

• 15% of a team’s capacity to technical debt and refactoring,
• 10% of a team’s capacity to bugs, and
• 5% of a team’s capacity to explorative spikes (when potentially helpful).

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

Question 22: Assigning User Stories

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

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

Question 23: Cherry-Picking Items

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

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

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

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

Question 24: The Almost Ready User Story

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

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

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

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

Question 25: Sprint Planning Is a Waste of My Time

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

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

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

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.

How To Use The Scrum Master Interview Questions

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

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

So, go for a pragmatic veteran who has experienced failure in other projects before and the scars to prove it. Last, but not least: Being a “Certified Scrum Master” — or having any other certification of a similar nature — does not guarantee success.

Recommended Articles

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

Download the ’Scrum Anti-Patterns Guide’ for Free

The Scrum Master Trends Report 2019

22 Scrum Master Anti-Patterns from Job Ads

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

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

Do You Want to Read more like this?

Well, then:

• 📰 Join 27,128 peers and sign-up for my weekly newsletter
• 🐦 Follow me on Twitter and subscribe to my blog Age of Product
• 💬 Alternatively, join 8,200-plus peers of the Slack team “Hands-on Agile” for free.