TL; DR: Scrum Master Interview Questions on the Sprint Review
Scrum has repeatedly proven 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. A good starting point, though, is to ask a candidate about the intricacies of a Scrum event that puts the Increment, the Stakeholders, the Developers, and the Product Owner at heart, thus providing an excellent opportunity to reflect on the big picture. It is the Sprint Review.
Suppose you want to fill a Scrum Master (or agile coach) position in your organization. In that case, you may find the following interview questions helpful in identifying the right candidate. They are derived from my sixteen years of practical experience with XP and Scrum, as a Product Owner and Scrum Master, and my experience as a Professional Scrum Trainer with Scrum.org. Also, I have interviewed dozens of Scrum Master candidates on behalf of my clients.
So far, this Scrum Master interview guide has been downloaded more than 23,000 times.
🇩🇪 Zur deutschsprachigen Version des Artikels: Das Scrum Master Interview: Der Sprint Review.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes:
The Sprint Review According to the Scrum Guide
Are we still on track to accomplish the Product Goal? Moreover, how did the previous Sprint contribute to our Scrum team’s mission? Answering these questions and adapting the Product Backlog in a collaborative effort of the Scrum Team with internal and external stakeholders is the purpose of the Sprint Review:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
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. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Source: Scrum Guide 2020.
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 deep dive into a candidate’s understanding of Scrum and her agile mindset. First, 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 relevant 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).
Background Theses on the Sprint Review
Scrum Masters will be more successful once they understand that we are not getting paid to practice Scrum but to improve the lives of our customers. Understanding the big picture of both problem and solution space is mission-critical to a Scrum team’s success:
The Sprint Review is the only Scrum event formally inviting stakeholders to participate. There is a reason for this explicitness: The stakeholders’ participation is critical concerning the forthcoming investment decision, the next Sprint.
When the Daily Scrum serves the purpose of understanding whether the team is making progress toward accomplishing the Sprint Goal, the Sprint Review serves the purpose of understanding whether the team is making progress toward achieving the Product Goal.
The Sprint Review is the best moment to create or reaffirm the shared understanding among all participants whether the Product Backlog still reflects the best use of the Scrum team’s time.
The Sprint Review is an excellent place to close learning loops and reassure alignment between all parties.
The Sprint Review requires complete transparency to inspect the Increments and consequently adapt the Product Backlog to maximize the value delivered to customers within the given constraints while contributing to the organization’s viability.
“When can I have (the feature) and how much is it?” are legitimate questions of the stakeholders—they also need to do their jobs.
The Sprint Review is neither a celebration of the hard-won accomplishments of the Scrum Team. Nor is it an approval gate by the grace of the stakeholders.
A Sprint Review without stakeholders participating cannot serve its original function. The risk of the Scrum team living in a “bubble,” loving their solution more than the customers’ problems, increases.
Abstain from “demoing” the Increment or death by PowerPoint. Instead, make it worth it for stakeholders to invest their time by encouraging everyone to participate in the Sprint Review actively.
Scrum Master Interview Questions Set 5: The Sprint Review
Please find the following questions from the “Sprint Review” chapter to identify suitable candidates for the role of Scrum Master:
Q 1: 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.
Q 2: 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.
Q 3: 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.
Q 4: 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.
Q 5: 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.
Q 6: 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.
The Sprint Review — How To Best 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 their 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.) The larger the organization is, the more management levels there are, and the more likely failure is lurking around the corner.
The questions are not necessarily suited to turn an inexperienced interviewer into an agile expert. However, in the hands of a seasoned practitioner, they help identify the candidates who have been working in the agile trenches in the past.
The Scrum Master Interview: Related Posts
✋ Do Not Miss Out and Learn more about Scrum Master Interview Questions or the Sprint Reivew — Join the 11,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 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.
The article Scrum Master Interview Questions: The Sprint Review was first published on Age-of-Product.com. (Shaun?)