Scrum Master Interview Questions and Answers III

Scrum Master Interview Questions and Answers contains the most frequently asked questions that you might face in an Advance Scrum Master or SAFe Scrum Master interview & this will help you competently crack the Scrum Master interview. Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum Master Interview Questions and Answers will help you in accessing your knowledge & skills as a Scrum Master. Please read Agile Interview Questions and Answer for questions related to Agile Fundamentals. Scrum Interview Questions and Answer for questions related to Scrum Fundamentals.

Scrum Master Interview Questions and Answers – Part I: Click Here.

Scrum Master Interview Questions and Answers – Part II: Click Here.

Scrum Master Interview Questions and Answers

Question: What is Scope Creep & how do you prevent scope creep from happening in the project?

Agile Scope Creep describes how a project’s requirements tend to grow over time, goals, or vision changes beyond what was originally agreed upon. Scope creep is frequently caused by changes in project requirements from key stakeholders (not properly defined requirements and additional features are added to an existing product), as well as internal miscommunication and conflicts. 

Remember It is not Agile Scope Creep if you are changing something before the team has started to think about the details or if it doesn’t create additional work for anyone. So use just-in-time planning- have a clear iteration plan with high-level requirements. Work out the details of the iteration just before the iteration is started.

So, in order to prevent Agile Scope Creep, you first need a clearly defined project scope. In order to identify and establish your project scope, follow these five steps:

• Start with the “why.” Why are you and your team working on this project? What do you hope to accomplish? Knowing the size and scope of what you intend to achieve will help you define your project scope.
• Bring in your project objectives. Your project objectives and project scope are tightly linked. Your project objectives define the aim of your project, and they, in turn, have to fit within your project scope.
• Write down your project scope. Remember, this doesn’t have to be very long. Your project scope is just a place for you to clearly outline your project deliverables and how they relate to your project objectives. Feel free to use bullet points, too.
• Review your project scope. Make sure you get buy-in from stakeholders, and that everyone is aligned on the project deliverables, objective, and scope.
• Make adjustments if necessary. If you weren’t aligned in step four, take some time to rewrite your project scope. Before finalizing it, surface the document to your stakeholders again, to ensure buy-in.

Here are a few examples:

• Project stakeholders want to prioritize different features.
• Managers or senior team members want to keep clients happy.
• Not properly defined requirements and additional features are added to an existing product.
• Not a clear product vision for stakeholders.
• Items in the backlog are not assigned accurate priority levels.
• Items in the backlog lack clarity and depth despite being a high priority.
• Teams are pushed into an iteration (or sprint) without clear goals.
• Changes are introduced or forced into the middle of an iteration.
• New features are rushed into development without proper requirements or cost analysis.

Question: If you prevent scope creep from happening in the project how can you say that the project is Agile? Because agile is all about making changes to the project in an efficient way?

In an agile framework, scope creep is really a problem caused by injecting new or unplanned work into the middle of an iteration, rather than adding scope to the overall project. All agile frameworks solve this through formal processes and ceremonies. In Scrum, for example:

• New work should generally only be introduced during Sprint Planning.
• New work that takes priority over current work required early termination of the current Sprint, and a return to Sprint Planning.
• New work for the project must be prioritized by the Product Owner in collaboration with the stakeholders, so scope creep at the project level is managed through consensus that the proposed work is relevant to the project’s goals.
• In Scrum, iterations are a fixed time-box with a relatively fixed cost (excluding capital costs), but the scope is a variable constraint.
• “Scope creep” in the traditional business sense of the term will extend the total run-time of the project. By adding scope to the project, you impact the schedule (generally making it longer). You manage this through transparency and effective communications with stakeholders.

Kanban and Lean have similar mechanisms for managing change. The point is that there’s no free lunch. Adding scope adds cost or time to the project. You can’t fix cost, schedule, and scope at the same time, so the increased scope will generally increase a project’s costs and schedule as well, while often reducing overall quality as the organization attempts to increase scope without increasing costs or extending the schedule. As a Scrum Master, you need to be able to articulate the trade-offs for the project. 

Question: How would you handle a scrum transition of an organization that was heavily reliant on the Waterfall model before?

The most important thing when transitioning to Scrum is to first listen and observe everything and everybody. Try to conduct as many interviews as you can with literally everybody in your organization – QA, UX, UI designers, product managers, developers, etc. 

This will allow you to identify existing underlying problems in your organization. 

Here are a few ways how you can handle scrum transition from the Waterfall model:

• Make sure you have experienced people in the team having a thorough knowledge of scrum
• Upgrade the project management tools that you have been using currently
• Conduct a completely dedicated retrospective meeting
• Conduct scrum-related workshops, user stories, time and cost estimations, on-site practices, collaboration tools, and other tasks

Following the below-mentioned steps will ensure a smooth transition from waterfall to scrum.

Step 1: Conduct an agile audit to define an implementation strategy with success metrics. Find Current processes, Future processes, Step-by-step plans, Benefits, Potential challenges & Success factors.

Step 2: Build awareness and Strengthen product shared vision. Educate people, Use a variety of communication tools, Highlight the benefits, Share the implementation plan, Involve the initial scrum team & Be open/flexible.

Step 3: Form a transformation team and identify a pilot

Step 4: Planning for the Transformation (detailed transition plan with clear milestones).

Step 5: Training in Agile and Scrum

Step 6: Scrum or Agile Coaching

Step 7: Iterate the Plan

Step 8: Gather feedback and improve

Step 9: Mature and solidify improvements. Use models like the Shu-Ha-Ri stages.

Step 10: Progressively expand within the organization. To do this start with the following: Support new teams, Redefine metrics, Expand methodically, Identify new challenges, and Continue learning.

Question: What are the anti-patterns that a scrum master might fall during a sprint execution?

The anti-patterns include the following:

• Defining technical solutions – Keeping the Scrum team dependent on Scrum Master.
• Lack of support
• Assigning sub-tasks to the developers
• Flow disruption
• Doesn’t educating stakeholders on the negative impact of disruptions
• Doesn’t object that the management invites engineers to random meetings
• Doesn’t oppose line managers assigning other tasks to the team members
• Allows stakeholders or managers to turn the Daily Scrum into a reporting session
• Turns a blind eye to mid-Sprint changes of priorities by the Product Owner.

Question: How will you know that agile practices are working perfectly for your organization?

There is no standard definition for” Agile Success”. Every organization must develop its own criteria to evaluate whether the adoption of agile was a success or not. Here are a few things to consider:

• When the products you deliver to the end-user result in higher customer retention rates, upsells, and more customer acquisition.
• When the team genuinely feels happy, it can be considered that you are doing alright. There are no team members complaining about work environments. Nobody is leaving (or getting fired) the team.
• Increased software quality can be easily demonstrated by measurably less technical debt, less time on maintenance, and fewer bugs
• Stakeholders are increasingly participants in the event
• If there aren’t piles of technical debt, bugs aren’t present, there’s less time spent on maintenance, and reduction in the lead time then you can say that Agile is going well in your company.

Key questions to find out if the agile practices are working perfectly for your organization

• Is your organization willing to dedicate a full-time business expert, called a product owner?
• Is your organization willing to dedicate a full-time delivery team?
• Is your organization willing to provide a business analyst to elicit just-in-time (JIT) requirements?
• Is your organization willing to time box each iteration?
• Is your organization willing to put the right people in the right roles?
• Is your organization willing to support a collaborative environment?
• Is your organization willing to apply the necessary discipline?

Assess Agile Team Maturity – Levels of Maturity

• Level 0 – No Capability
• Level 1 – Beginning
  The team has some passing knowledge from reading books & articles. They are not yet applying the knowledge or are applying it on an ad hoc basis.
• Level 2: Learning
  The team actively tries to apply knowledge from training, books, and coaching.
• Level 3: Practicing
  The team understands the practice and uses it regularly.
• Level 4: Measuring
  The team applies advanced concepts and/or is using metrics to measure their abilities and effectiveness.
• Level 5: Innovating
  The team actively experiments with new methodologies and practices and is using metrics to measure the effect.

Question: How do you handle developers who consider daily Scrum to be a waste of time and therefore avoid them?

This can be quite a severe problem for the team environment. Such members can turn out to be quite toxic at their core and convey only negative vibes, ruining the team’s spirit and productivity. 

Here’s how you can address the situation:

1. Privately discuss, with the team member in question, their motives and attitudes. Try to figure out what’s going on in their head. Maybe they need to be further trained on the principles of Scrum.
2. If no change has occurred in the developer’s attitude afterward, it’s advisable to schedule a meeting with the department manager.
3. If you still can’t align the particular developer’s vision with your own and the team’s, then it might be reasonable to reassign the developer to a different team, a Kanban team for example, where they won’t be forced to step out of their comfort zone.

Question: What are the anti-patterns that a scrum master might fall during a sprint review?

The Product Owner: 

Selfish PO – Use sprint review as an opportunity to present “his or her” accomplishments to the stakeholders., 

Solution: Coach the PO on Scrum values of commitment, courage, focus, openness, and respect.

Acceptance for user stories – The Product Owner uses the Sprint Review to “accept” tasks/Product Backlog items.

Solution: Ideally the Product Owner should constantly communicate with the Developers & adjust when the increment deviates from acceptance criteria.

Unapproachable PO – The Product Owner is not accepting feedback from stakeholders or the Developers. 

Solution – Coach the PO on Scrum values of commitment, courage, focus, openness, and respect & explain why such behavior violates the prime purpose of the Sprint Review event.

The Scrum Team:

No Sprint Review: There is no Sprint Review,

Solution: Sprint Review is necessary to create transparency, so coach the scrum team on the importance of these events in the scrum.

Too much documentation or presentation – Participants are not engaged due to heavy documentation.

Solution: The foundation of a successful Sprint Review is “show, don’t tell,” or even better: let the stakeholders drive the discovery.

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.

Solution: Coach that creating transparency and receiving feedback is the purpose of the exercise.

Sprint accounting: Every task accomplished is demoed, and stakeholders do not take it enthusiastically.

Solution: Tell a compelling or important story of interest at the beginning of the review to engage the stakeholders. Do not bore stakeholders by including everything that was accomplished.

The Stakeholders:

Stage-Gate approval – The Sprint Review is a kind of stage-gate approval process where stakeholders sign off features. 

Solution: Probably hybrid Agile-Waterfall model is followed. Coach the stakeholders on the benefits of Agile principles and Manifesto.

No stakeholders: Stakeholders do not attend the Sprint Review.

Solution: Find the reason behind stakeholder disengagement like they do not see any value in the event, or it is conflicting with another important meeting, or do not understand the importance of the Sprint Review. Then you need to convince them of the importance of the event and their participation.

No customers/users: External stakeholders—also known as customers—do not attend the Sprint Review.

Solution: Invite actual users to these sprint review and engage them by allowing to use the product.

Starting over again: There is no continuity in the attendance of stakeholders.

Solution: Coach stakeholders so that they understand the importance of Sprint Review & attendance. The impact of missing sprint reviews on their ability to provide in-depth feedback.

Passive stakeholders: The stakeholders are passive and unengaged. 

Solution: Let the stakeholders drive the Sprint Review or make it interesting by allowing stakeholders to play with the product.

Question: How is the estimation in a Scrum project done? What are the techniques used for analysis?

The estimation is done using comparative Agile estimation methods in a Scrum project:

• The T-shirt or White Elephant Estimation Technique
• The Affinity Estimation Technique
• The Bucket System Technique
• The Planning Poker Estimation Technique
• The Estimation by Analogy Technique
• The Disaggregation Estimation Technique

Question: What are the anti-patterns related to the Product Backlog which you need to keep at bay?

There are few anti-patterns that occur in almost all organizations

• Product Backlog Prioritization by proxy: Instead of Product Owner stakeholder(s) prioritizing the Product Backlog.
• Full Product Backlog refinement in Advance: Scrum Team expects and does the product backlog refinement for the whole project in advance before starting sprints.
• Oversized items in Product Backlog: The Product Backlog contains more items than the Scrum team can deliver or the items are too large to accommodate in a. sprint.
• Storage for ideas: The Product Owner is using the Product Backlog as a repository of ideas and requirements. This clogs Product Backlog and leads to cognitive overload and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very tough.
• Order taking PO, Submissive team, or non-engaged team: The Product Owner breaks down requirement documents received from stakeholders into smaller chunks without involving the scrum team or Developers submissively following the demands of the Product Owner.
• No time for refinement: The Scrum team does not have enough refinement sessions, resulting in a low-quality Product Backlog.
• Too much refinement: The Scrum team has too many refinement sessions, resulting in a too detailed Product Backlog.

Question: What are the anti-patterns related to Sprint Planning that you need to keep at bay?

There are few anti-patterns that occur in sprint planning

• The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision.
• 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.
• Unfinished work items from the last Sprint spill over into the new Sprint without any discussion.
• The Product Owner tries to squeeze in some last-minute Product Backlog items that are not ready yet.
• 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.
• The Product Owner does not prepare the Product Backlog to provide useful Product Backlog items for selection by the Developers.

Question: What are the anti-patterns related to Sprint Retrospective which you need to keep at bay?

There are few anti-patterns that occur in the sprint retrospective 

• The team does not collectively value (little or no value) the Sprint Retrospective. This may occur for various reasons like the same procedure every time, same venue, stakeholders being absent or participating by force, etc.
• The Sprint Retrospective never changes, the team revisits the same issues over and over again in each sprint retrospective.
• The team postpones the Sprint Retrospective to the next Sprint.
• No one is taking minutes for later use.
• The Sprint Retrospective is an endless cycle of blame and finger-pointing. Few team members are dominating the Sprint Retrospective.
• The team members are present but are not participating due to various reasons like they regard the Sprint Retrospective as a waste of time, or hostile environment to discuss the improvements, or the participants are bored to death by its predictiveness.

Few tips to avoid these anti-patterns

• Don’t force team members to participate in the scrum retrospectives. It’s probably the scrum master’s fault for not making the meeting worth the team members’ time.
• Developers should be fueled by motivation & inspiration, not by fear and order.
• Don’t postpone items for the next retrospective.
• Suppose there’s a blame culture going on during the sprint retrospective. In that case, you should take measures to prevent that from happening further down the road. Otherwise, your team might completely break up.

Question: Why are the user stories not estimated in man-hours?

One of the most common approaches for evaluating teamwork is to estimate in man-hours. While man-hours are simple to comprehend, they have a number of significant drawbacks:

Few activities, such as legacy work, are difficult to estimate precisely.

• If one team member delivers the estimate but the task is completed by another, the estimate is useless.
• The amount of time it takes to perform a task depends on the developer’s level of experience.
• Teams frequently overestimate the obstacles they may face and simply consider the best-case scenario.

The benefits of estimating user stories in points include the following: There is no association between the estimator’s skills and experience, and story points are independent of the story’s author. The team members can estimate more correctly since story points are a measurement of relative sizes, and the size of the story cannot be changed by external forces. As team behavior takes precedence over individual conduct, Story Points encourages collaboration. The team comes together when they use planning poker to estimate story points. As teams exchange, constructively criticize, argue, and have fun playing poker cards to arrive at an agreement on estimations, it serves as a team-building activity.

Question: What are the five steps of Risk Management?

To manage risk, there are five essential measures to follow. They are as follows:

Identification of Risk: The first step is to determine the risks that the company faces in its current operational environment. There are numerous forms of risks, including legal risks, environmental risks, market risks, regulatory risks, and so on. It’s critical to recognize as many of these risk variables as possible.

Analysis of the Risk: It is necessary to examine a risk once it has been recognized. The risk’s scope must be assessed. It’s also crucial to comprehend the relationship between risk and other internal components. It is crucial to establish the severity and importance of the risk by looking at how many business operations it affects.

Ranking the Risk: Risks must be prioritized and ranked. Based on the intensity of the risk, most risk management solutions have several risk categories. Risks that can result in serious loss are ranked the highest, while risks that may cause some inconvenience are rated the lowest.

Treating the Risk: Every risk must be minimized or eliminated to the greatest extent practicable. This is accomplished by contacting specialists in the field to which the risk pertains. In a manual situation, this means calling each and every stakeholder and then scheduling meetings for everyone to talk about and debate the concerns.

Reviewing the Risk: The risk is then reviewed to ensure that the risk has been eliminated completely.

Question: What are suitable Agile metrics for leading Scrum?

First, you need to use metrics that concern the team as a whole and avoid individual metrics.

Second, consider context as well. For example, members being on holiday or on sick leaves can result in changes in your metrics.

Examples of suitable agile metrics are:  

• Lead time.
• Cycle time.
• Many defects escape to production.
• The ratio of fixing work to create new value.

Question: Differentiate between MVP and MMR.

Minimum Viable Product (MVP) is a Lean Startup concept that emphasizes the importance of learning while developing a product. This enables one to test and understand the concept by exposing target consumers and users to the initial version. To accomplish this, one must first gather all pertinent data and then learn from it. The MVP concept is to create a product, provide consumers access to it, and observe how the product is used, perceived, and understood. This will also give you a better idea of what the needs of your clients or users are. Successful products are released into the market in stages over time, with each “significant” deployment referred to as a release.

MMR (Minimum Marketable Release) is a product release with the minimal possible feature set that solves your customers’ current new needs. MMRs are used to shorten time-to-market between releases by condensing each release’s coherent feature set to the lowest increment that provides new value to customers.

Question: Can the Scrum team be involved in the product discovery process? If so, explain how.

Making the scrum team a participant in the discovery process early in the product development lifecycle is quite beneficial. Agile refers to teams engaging with stakeholders early in the development process so that both parties are on the same page. Consider some of the benefits of early involvement:

• The development teams can help in modifying the specifications with the client by identifying technical implementation issues early in the process.
• Along with the product owner, the team begins to share a shared knowledge of what needs to be built. Teams can sometimes assist the product owner in detecting requirements that might have been overlooked.
• They have a common concept of what needs to be constructed. It also helps teams stay dedicated and confident, encourages them to take ownership of their job, and, most importantly, increases team spirit.
• To help with this, the scrum master can begin including the teams in early product discussions when the requirements are still vague. The product backlog can be built by the team and the product owner.

Question: Your team is failing to meet deadlines, and its velocity is volatile. What are the most probable reasons for that? How would you handle such a situation?

Many factors make a Scrum Team’s velocity volatile: 

• New team members are unfamiliar with the environment and the organization’s ways of doing things.
• Developers leaving the team or getting fired.
• The team working on projects that aren’t anything similar to what they’ve encountered before.
• Unexpected technical debt and bugs.
• Holidays, sick leaves, maternity leaves.
• Scope changes.
• The product backlog is just a mess. Developers struggle with selecting primary tasks and instead end up working on secondary assignments.

Question: As a new scrum master, what challenges are you aptly to encounter?

One of the biggest challenges you might stumble upon as a beginner scrum master is burn-out. The tons of meetings you have to attend, emails you need to send, and reports you should create can seem like energy vampires at first.

Keeping the development team and other stakeholders on the same page can also be a difficult task. For this purpose, you need to create thoroughly detailed reports to convey the project’s progress to the stakeholders. Keep task details clear and transparent in the backlog so that the scrum team can explicitly see the next step ahead of them.

Disclaimer: All the content related to Scrum Guide is taken from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.