38 Scrum Master Interview Questions
Maybe, “Agile” in general is a more a kind of management fad but a trend at the moment. But what we can say for sure is that Scrum has become very popular for software development purposes. Demand for seasoned Scrum practitioners is on the rise and so is the market-entry of new professionals from other project management branches, probably believing that reading one or two Scrum books will be sufficient.
If you are looking to fill a position for a Scrum master (or agile coach) in your organization, you may find the following 38 interview questions useful to identify the right candidate. There are derived from my ten years of practical experience with XP as well as Scrum, serving both as Product owner and Scrum master as well as interviewing dozens of candidates on behalf of my clients.
Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario, just best practices that have worked in other organizations before. Hence, you will have to figure out on your own what is working for your organization–which is a process, not a destination.
So, the role of the Scrum master or agile coach in my understanding is primarily about leadership and coaching, but not about management. And most definitely, the Scrum Master role is not about “process enforcement”. Which is also the reason that the repository contains to a large part questions that are addressing a candidate’s soft skills.
The questions are, however, neither suited, nor intended to turn an inexperienced interviewer into an agile expert. But in the hands of a seasoned practitioner they support figuring out, what candidate has actually been working the agile trenches in the past and who’s more likely to be an imposter.
You don’t have to copy & paste the question for your personal interview script–just download the PDF, see the link below.
The questions themselves are grouped into five categories: The role of the Scrum master, backlog grooming and estimation, sprint planning, standups and retrospectives.
I. The Role Of The Scrum Master:
i. Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario, just best practices that have worked in other organizations before.
ii. Hence, you have to figure out on your own what is working for your organization, which is a process and not a destination.
iii. Securing the support of the C-level is an essential success factor for any agile methodology. Scrum will have a significant impact on how the organization will build new product in future. The senior management members have to be an outspoken supporter of the idea, otherwise Scrum will fail.
iv. A Scrum master/agile coach is therefore primarily about leadership and coaching, but not a management role.
v. It is definitely not about "process enforcement".
vi. Scrum is not built for bean counters. Some metrics are helpful to understand the health of a Scrum team, but generally, it does not help insisting on "meeting KPIs", e.g. commitments vs. velocity.
vii. Beware of the “depression phase” after an enthusiastic start, when reality kicks in. Scrum is not easy, it requires change management at an organizational level.
viii. Scrum does not have much to say about the process that enables the Product owner to fill the backlog with valuable, usable and feasible user stories. Product discovery based on Lean UX, Design Thinking or Lean Startup are some idea may help in the process. A good Scrum master wants her team to be a part of this process, for example participating in user interview or running experiments.
ix. The team's communication with stakeholder should not be run through a gatekeeper process, e.g. solely through the Product owner. That would hurt transparency and negatively affect the team's performance. Sprint demos are therefore a good way to not only present the value delivered by the team in the sprint before, but also to stay in close contact with stakeholders.
i. The Agile Manifesto says "People over processes". Isn't the Scrum master – a role to enforce "the process" – therefore a contradiction?
ii. What are good indicators that "Agile" is working in your organization, that your work is successful?
iii. Are there typical metrics that you would track? And if so, which metrics would you track and for what purpose?
iv. Your team's performance is constantly not meeting commitments and its velocity is very volatile. What are possible reasons for that? And how would you address those issues?
v. Shall the Scrum team become involved in the product discovery process as well, and if so, how?
vi. The Product owner role is a bottleneck by design. How can you support the Product owner so that she can be the value maximizer?
vii. How do you ensure that the Scrum team has access to the stakeholders?
viii. How do you spread an agile mindset in the company across different departments and what is your strategy to coach these non-IT stakeholders?
ix. How do you introduce Scrum to senior executives?
x. You already performed Scrum training to stakeholders. After an initial phase of trying to apply the concepts, when first obstacles/hurdles are encountered, you see that these colleagues build serious resistance in continuing with Scrum adoption. What are your strategy/experience to handle such situations?
II. Backlog Grooming And Estimation:
i. Estimation and backlog grooming are essential tasks for every team. While the Product owner – at least officially – is in charge of keeping the backlog at peak value delivery, she will need the assistance of the whole Scrum team to do so.
ii. In the ideal scenario, this requires a cross-functional and co-located Scrum team that can work independently from other Scrum teams.
iii. The reality in most cases is, however, that the team might be dependent on deliveries from other teams (e.g. API endpoints) or deliverables from the UX/UI department.
iv. There are two essential ingredients for a good team performance/velocity:
1. Writing user story is team work:
a. The Product owner explains why something shall be built and provides the necessary background, e.g. market intelligence, results from experiments and user interviews or statistical data.
b. She then creates a corresponding user story (or user stories) in a joined effort together with the team to achieve a shared understanding on the why and how as well as a sense of ownership among all team members.
2. "Definition of Ready": The Scrum team and the Product owner also need to agree on a "Definition of Ready" for user stories to ensure a flow of well-drafted stories for the development process. It is an agreement on what needs to be provided to call a user story ready for estimation. If one of these requirements is not met, a user story isn't ready for estimation. And a user story without a previous estimation is not ready to become a part of a sprint backlog, as the team won't be able to commit to an unknown entity of the sprint. The Scrum team needs to learn to say "No"
ii. .A well-groomed product backlog has probably user stories for about 2-3 sprints in a more detailed manner, less than half of which probably meet the "Definition of Ready" criteria of the team. There may be some additional user stories that no one except the product owner is working on at the moment.
i. The Product owner of your team normally turns stakeholder requirement documents into tickets and asks to estimate them. Are you fine with that procedure?
ii. What kind of information would you require from the Product owner to provide the team with an update on the product and market situation?
iii. Who shall be writing user stories?
iv. What shall a good user story look like? What is it structure?
v. What should a "Definition of Ready" comprise of?
vi. Why aren't user stories simply estimated in man-hours?
vii. The Product owner of your Scrum team tends to add ideas of all kind to the backlog to continue working on them at a later stage. Over time, this has lead to over 200 tickets in various stages. What is your take on that: Can the Scrum team work on 200 tickets?
III. Sprint Planning:
i. Traditionally, the Product owner would explain high-level user stories of a high value from the product backlog to the Scrum team and the team would then turn them into a more detailed user stories and estimate them.
ii. Turns out, though, that working on user stories in separate backlog grooming and estimation meetings before the sprint planning actually improves the quality of the stories and thus the outcome of the team's work.
iii. A good practice is to run weekly product backlog grooming and estimation sessions and only allow user stories that meet the "Definition of Ready" standard of the Scrum team into the sprint planning.
iv. With all uncertainty eliminated, the sprint planning then creates a sense of ownership among the member of the Scrum team for the sprint backlog items, as the team now can make a valid commitment.
v. The sprint planning is therefore divided into two parts:
1. Sprint planning I: The Product owner presents her choice of the most valuable user stories from the product backlog to the Scrum team and the team picks – taking all circumstances into consideration, for example available capacity, – those stories it can commit to a delivery by the end of the sprint.
2. Sprint planning II: The Scrum team adds details to the user stories of the sprint backlog, e.g. splitting them up into tasks, identifying parts that need further clarification or agreeing on who will be working on what tasks. The Product owner does not necessarily need to participate in the sprint planning II, but needs to be on stand-by for additional questions.
3. If the user story preparation process is handled well, the whole sprint planning may take no longer than 2-3 hours.
ii. A productive sprint planning requires a healthy team. Dysfunctional teams will not meet the required level of cooperation. It will be a futile and painful exercise.
iii. A team should usually avoid allocating more than 75% of the capacity to new user stories. Bugs, refactoring and research require regular attention, too, if you want to avoid building up technical debt.
iv. Insufficiently prepared user stories seriously hamper the flow and efficiency of the Scrum team. They should be never be picked for the sprint backlog in the first place, but sorted out during backlog grooming and estimation meetings.
i. How can you as a Scrum Master contribute to the sprint planning in a way that the team is really working on the most valuable user stories?
ii. On what metrics would you base the assessment of the value of a user story and what metrics would be not acceptable?
iii. How do you facilitate the user story picking progress in a way that the most valuable stories are chosen without overruling the team's prerogative to define the team's commitment?
iv. How much capacity would consider to be adequate for refactoring, fixing important bugs, exploring new technologies or ideas?
v. How do you deal with a Product owner that assigns user stories or tasks to individual team members?
vi. How do you deal with cherry picking tasks by team members?
vii. A user story is lacking the final designs, but the design department promises to deliver on day #2 of the upcoming sprint. The product owner of your Scrum team is fine with that and pushes to have the user story in the sprint backlog. What is your take?
viii. A member of the Scrum team does not want to participate in the sprint planning meetings but considers them a waste of time. How do you deal with that attitude?
i. Standups are well suited to discuss the state of progress: is all going as planned or does the team need to adjust?
ii. It is also one of the moments that the Scrum team can meet and communicate with the stakeholders.
iii. Standups cannot fix a dysfunctional organization or team, an inadequate backlog, a sprint planning gone wrong, low quality user stories, a missing product vision – you get the idea.
iv. Standups are good, if the team is already collaborating well and the basics are in order: backlog building, estimation/grooming, sprint planning etc.
v. However, the more experienced the team is, the better the internal communication, the more the standup will seem to be time-consuming ritual of little value. A two people team does not necessarily need a formalized standup, grabbing a coffee together might be valid alternative.
vi. If impediments are not communicated before the next standup, then something is wrong within the team. Maybe, it is more a group than a team?
vii. Offline boards are great, as taking a card and moving it always represents a different level of ownership of a user story. If you have to let go either the online or the offline board, consider the online board, if you're a co-located team.
i. Would you recommend standups for all teams no matter their size or experience level?
ii. Do you expect experienced team members to wait until the next standup to ask for help with an impediment?
iii. How do you handle team members that "lead" standups, turning them into a reporting session for them?
ix. How do you handle team members that consider standups to be a waste of time and therefore are either late, uncooperative or do not attend at all?
i. No stakeholder is attending your team’s standups. How do you change that?
ii. How do you approach standups with distributed teams?
iii. Can you draw a draft of an offline Kanban board for a Scrum team right now?
a. Background (not a part of the original blog post):
i. Retrospectives will only work in favor of improving the team's collaboration and thus performance, if they are a safe place to provide honest, yet constructive feedback.
ii. Rule #1: Absolutely no blaming of others, everyone should be focused on how to improve the situation.
iii. Some teams include the Product owner right away, others insist on that the Product owner needs explicitly be invited.
iv. Change places regularly; it helps not to have the retrospective at the team's working place. Any distance makes reflection easier and prevents boredom or team members checking out completely.
v. Change the format regularly, running the same format more than twice is not recommended.
vi. Make it a smartphone, tablet and laptop free zone, so no one will be distracted but can fully focus on contributing to the round.
vii. Document all the issues, at least temporarily on Post-its. (Better to have them in a document as well.)
viii. "What went right, what went wrong, and what to improve" is the typical set of questions
ix. An alternative set might be "What to introduce, what to keep doing, and what to stop doing", eventually enhance by "what to do more of" and "what to do less of". (Starfish retrospective.)
x. Another alternative is the “Mad-Sad-Glad” technique that works well especially at the end of the year (in general after a longer period of time), after changes, after encountering drawbacks/pressure or outstanding achievements in a Scrum team. Usually this kind of retrospective instills emotional self-expression and helps uncover points of frustration and devise strategies to overcome them.
xi. Action items and improvement tasks:
1. Make actions items falsifiable. "Do x more often" does not match that criteria.
2. Make a single team member responsible for a single action item.
3. Don't forget to check on the action items of the last retrospective.
4. It is useful to put action items on a Kanban board in order to be able to better track their progress.
i. Who shall participate in the retrospective: just the Scrum team or also the Product owner?
ii. Do you check the team health in a retrospective or isn't that necessary? If so, how would you do it?
iii. What retrospective formats have you been using in the past?
iv. How can you prevent boredom at retrospectives?
v. A team is always picking reasonable action items, but is later not delivering on them. How do you handle this habit?
vi. How do you recommend following up on actions items?
My best advice for the interview is to move as fast as possible from meta-level to ground level. Don’t invest too much time on discussing the advantages of agile methodologies and theoretical concepts.
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 perform as a team–remember Tuckman’s model of team forming https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development –, is a complex task. (As always you might say when humans and communication is involved.) And the larger the organization is, the more management level there are, the more likely failure is lurking around the corner.
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 either.
PS: Two to three questions from each category will provide more than enough ground for a engaging 60 min conversation.
PPS: If you like to relax the candidate as well as make the interview more interesting at the same time, ask her to draw an offline board for a Scrum team. The board is a perfect hook for a lot of questions.
Article written by: Stefan Wolpers
Bio: Wolpers has been working for 10+ years as a product owner and agile coach/Scrum master and is a member of Scrum Alliance (CSPO, CSM). During that time, he has developed B2C as well as B2B software, mainly for startups, including a former Google subsidiary.
Scrum Alliance profile: https://www.scrumalliance.org/community/profile/swolpers
For the download of the PDF, please follow the link below:
The PDF contains also guidance on appropriate answers to the each of the 38 questions.