Scrum master interview questions and answers

What is the difference between Agile and Scrum?

Agile is a philosophy about how teams should develop software, while Scrum is a lightweight framework that guides teams as they embark on a product development journey.

Agile is based on the Agile Manifesto, which consists of 12 principles and four fundamental tenets including the following:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The Agile Manifesto is fewer than 500 words long. In contrast, the Scrum Guide is 10 times that size. It includes actionable insights on how to structure a development sprint, along with rules about the length and frequency of important Scrum events such as the following:

• The daily Scrum.
• Sprint planning events.
• The sprint review.
• The sprint retrospective.

Agile is a philosophy about how software development should be done, while Scrum is an actual framework.

How do you deal with developers who complain that there are too many meetings in Scrum?

If anyone insists that there are too many meetings in Scrum, I always ask them which ones they'd like to remove:

• Should teams skip sprint planning?
• Should teams forgo sprint retrospectives to look for improvements?
• Should teams not conduct sprint reviews to share their progress with the client?
• Should developers not meet briefly each day to discuss progress?

Each meeting in Scrum serves a specific purpose. Moreover, Scrum's events, and the transparency of its artifacts, are designed to eliminate the need for other meetings. This means Scrum actually should result in fewer meetings than efforts driven by other frameworks.

If an organization schedules meetings outside of the events prescribed by the Scrum Guide, that is an impediment the Scrum master should work to remove.

What are the three daily Scrum questions, and should they be asked in the daily Scrum?

The standard three daily Scrum questions are as follows:

1. What did you do yesterday?
2. What do you plan to do today?
3. Are there any impediments that block your progress?

The three daily Scrum questions were removed in the 2020 Scrum Guide -- not because they are bad or ineffective, but because teams shouldn't feel obligated to ask and answer them every day.

Developers on the team should determine the format and structure of the daily Scrum.

The goal of the daily Scrum is to inspect progress and, if necessary, adapt the Scrum plan to ensure the sprint goal remains in focus. If those three daily Scrum questions help developers achieve that end, then they are well within their rights to ask them.

However, if the team has other effective strategies to keep the sprint plan on track, they shouldn't feel that asking the three daily Scrum questions is a requirement.

Who in your organization should be the product owner in Scrum?

In a perfect world, the product owner is a dedicated position, not a part-time role for an underutilized project manager or marketing team member.

Every Scrum product owner should possess the following characteristics:

• A vision for the product being built and an idea of how that vision will roll out over time.
• An understanding of how to balance the needs of many stakeholders.
• An ability to prioritize the product backlog in a way that maximizes the value of the product that gets built.

What takes a product owner from good to great is the trust they've earned among their peers.

That means the organization and the stakeholders trust this person to make timely decisions on how the product should be built. It also means the Scrum teams trust the product owner to make fair and final decisions that managers won't overrule.

When an individual bearing these qualities is identified, the organization has found an effective product owner.

What's the difference between a servant leader and a leader who serves?

The 2020 Scrum Guide changed references of the Scrum master from a servant leader to instead a leader who serves.

The reason for that subtle but significant change is that the Scrum master is a leader first, and while they lead, their ongoing desire is to serve the team best.

Scrum masters are leaders first, who serve.

How actively should the Scrum master participate in the daily Scrum?

Scrum masters shouldn't actively participate in the daily Scrum at all.

The daily Scrum is an opportunity for the developers to discuss progress and motivate each other as they move closer to the end of the sprint.

The daily Scrum is for the developers, and run by the developers. Neither the product owner nor the Scrum master should be active participants in the daily Scrum.

If the developers must call upon the product owner to answer a question, that's fine. If the developers want the Scrum master to attend and provide coaching or feedback regarding how to get more out of the daily Scrum, that is allowed as well.

However, a Scrum master's or product owner's involvement in the daily Scrum must be at the behest of the developers. Otherwise, they shouldn't actively participate at all.

What's the difference between Kanban and Scrum, and can teams mix them together?

Scrum is an iterative and incremental product development framework that helps teams get started and keep going. In contrast, Kanban is more singularly concerned with visualizing how work and tasks move through the software development process.

Scrum describes itself as an incomplete framework. Teams can include best practices from various popular processes and methodologies into their development practices.

Many Scrum teams use Kanban boards to help gauge progress and minimize the amount of work in progress while they implement the various practices prescribed by the Scrum Guide.

Scrum always encourages teams to experiment, explore and embrace new practices that make them more effective. If a team believes Scrum and Kanban will help them better achieve their sprint goals, then they are definitely encouraged to experiment and combine them.

How long should an Agile sprint be?

The only rule the Scrum Guide provides about the length of an Agile sprint is that it must be a calendar month or less. Beyond that guidance, the established length is up to the team to decide.

The project's vulnerability to risk is one of the primary factors to consider when establishing how long or short a sprint should be. The further you envision a project into the future, the wider the cone of uncertainty becomes. To minimize risk, two-week sprints are preferable to ones that last a month.

At the same time, teams must also factor in stakeholder involvement. At the end of every sprint, stakeholders are expected to participate in a sprint review, which may take up to four hours of their time. If a Scrum team has sprints that last a week, stakeholders might get annoyed that their Friday afternoon calendar is blocked off indefinitely to inspect the team's progress.

New projects, where uncertainty is the greatest, often have short, two-week sprints.

As projects mature, the sprint length's duration might creep up to three or four weeks -- but under no circumstances should the sprint length ever exceed a single calendar month.

Who are the chickens and the pigs on a Scrum team?

According to an early edition of the Scrum Guide, the most committed members of an organization were the pigs. Everyone else was a chicken.

That definition typically meant the Scrum master, product owner and developers on the Scrum team were pigs. So too are perhaps a few stakeholders outside the Scrum team whose jobs might ride on the project's success or failure. Everyone else is a chicken; they contribute to the outcome but at less risk.

The peculiar allegory is from the chicken-and-pigs parable that says in a ham-and-eggs breakfast, the chicken is involved but the pig is completely committed.

The Scrum Guide no longer references this fable. The stewards of the framework felt it was better to address the topic of accountability directly as opposed to through metaphors.

What is ScrumBut?

The Scrum Guide says that Scrum is immutable. That means teams must implement Scrum in its entirety; otherwise, what the team is doing can't be considered Scrum.

ScrumBut occurs when teams make excuses for why they do not implement Scrum in a way that is fully aligned with the Scrum Guide. Some examples include the following:

• We do Scrum, but we don't do daily Scrums.
• We do Scrum, but we don't have sprint goals.
• We do Scrum, but our project has two product owners.

That's ScrumBut -- "Scrum, but …" -- and teams should avoid it at all costs.

What's the difference between being Agile and doing Agile?

The difference between doing Agile and being Agile is the difference between going through the motions and actually embracing an Agile philosophy toward work, life and relationships.

There are many tools on the market that help you do Agile. You can have a list of product backlog items in Jira and schedule monthly sprint retrospectives on Teams, and pay lip service to the continuous delivery of software to your clients -- but that doesn't actually mean you're being Agile. It just means you're doing Agile things.

To truly be Agile, you must embrace the concept that things constantly change, and constantly inspect and adapt to ensure your goals stay on target. That means you embrace an Agile mindset and push for Agile transformations throughout the organizations in which you work, not just in the localized development environment.

Being Agile takes far more effort and commitment than simply doing Agile, but the extra effort is worth the reward.