Scrum Master Interview Questions and Answers – II

Scrum Master Interview Q & A contains a list of top interview questions and answers which will help you to prepare and crack interviews related to Scrum Master. In this article, we will focus on the different areas under which questions are asked and what are the commonly asked questions for scrum masters. It 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 III: Click Here.

Scrum Master Interview Questions and Answers

Question: How do you help a Product Owner who is finding difficulty in breaking Epics into stories?

Answer: I facilitate backlog refinement meetings and work with the Product Owner and the Developers to agree on the scope and acceptance criteria for each proposed story. If a story, as defined, is too large to fit within a sprint, I support the team to create smaller stories that can be worked on to deliver value within multiple sprints. Other things you can talk about here:

• 3C’s (Card, Conversation, Confirmation)
• INVEST (Independent, Negotiable, Valuable, Estimate-able, Small, Testable)
• DEEP (Detailed Enough, Emergent, Estimated Relatively, Prioritized Ordered)
• SMART (Specific, Measurable, Achievable, Realistic, Time-Based)

Question: List out the disadvantages of Scrum?

Answer: It will be a tricky job for a scrum master to plan, organize and structure a project that lacks a clear goal.

• Daily scrum meeting requires frequent reviews and substantial resources. Sometimes it can turn into just a status meeting and the basic essence of scrum is lost.
• A successful project relies on the maturity and dedication of all the team members. In a few situations, we might not have mature, knowledgeable & dedicated team members.
• Uncertainty regarding the product, technology used, frequent changes, and frequent product delivery remains during the scrum cycle.
• It makes all dysfunction visible so the team has to dedicate time to fixing most of the time rather than developing. It requires significant change.

Question: Explain scrum of scrum?

Answer: There are multiple teams that usually work on the same product and in order to coordinate and communicate with different teams, it is required to organize a separate scrum meeting. The scrum meeting organized to hold coordination between scrum teams is known as the scrum of scrum. . The responsible person from each team generally Scrum Master attends the meeting and discusses their work and answers the questions like

• Since the last meeting, what is the progress of the team?
• What your team is expected to do or should accomplish, before the next meeting?
• What are the obstacles and dependencies your team faced while completing the task?

Question: If a leader came to you and explained they were budget-constrained and wanted to combine the Product Owner and Scrum Master role, what would you advise?

Answer: If they want to use Scrum, then there are three very well-defined roles.

Combining Scrum Master and Product Owner will not be effective because. The Product Owner role needs to focus on product decisions. Scrum Master activities would distract the Product Owner from that. Likewise for the Scrum Master role. Both the roles have different sets of activities and combining both will create a conflict of interest.

I’d advise getting a coach to work with the team for a short period, and then subsequently after a few sprints again perhaps one of the dev team members will scale up to take the Scrum Master role with some coaching.

Question: Give details of your experience in working with a team to break work down from an Epic size, to where it’s ready to come into a sprint?

Answer: A case study of how I worked with a customer and a development team to break a large product into smaller slices of work and user story mapping to prioritize that work.

I helped the customer break down the product features into manageable pieces of work, viewing it all from the end user’s point of view by using User Personas, then Story Mapping.

A second Case Study: At XYZ, I used the big picture stories to facilitate good conversations between the designer, developers, and the customer. With the developers having very early involvement, they were able to choose better technology and architecture for the project.

Question: How do you calculate the capacity and velocity of a Scrum team?

Answer: Velocity is calculated by averaging the number of completed story points in previous sprints. Velocity is used to determine the capacity—how many product backlog items the team should take for the next sprint.

Capacity shows how much availability the team has for the upcoming sprint. Other things held constant, the capacity should be equal to the velocity. However, a few factors can lower the capacity:

• Vacations
• Sick days
• Onboarding of new team members
• Other ad hoc company events or meetings

Question: What is MVP in scrum?

Answer: A Minimum Viable Product is a product that has just the bare minimum required feature which can be demonstrated to the stakeholders and is eligible to be shipped to production.

Question: You are in the middle of a sprint and suddenly the product owner comes with a new requirement, what will you do?

Answer: In an ideal case, the requirement becomes a story and moves to the backlog. Then based on the priority, the team can take it up in the next sprint. But if the priority of the requirement is really high, then the team may have to accommodate it in the sprint but it has to very well communicate to the stakeholder that incorporating a story in the middle of the sprint may result in spilling over a few stories to the next sprint. After verifying all aspects sprint backlog is adjusted.

Question: Should the scrum team become involved in the product discovery process, and if so, how?

Answer: The scrum team should be involved in the product discovery process as early as possible. There are two principal reasons for this:

• The sooner the engineers participate in the product discovery process, the lesser the chances are that solutions are pursued that are technically not viable, or that would not result in a return on investment.
• Early involvement ensures that the scrum team and the product owner develop a shared understanding and ownership of what is to be built. This significantly improves the likelihood that resources are allocated to the most important issues, maximizing value for the customer and mitigating investment risk. Involving engineers early in the process also ensures their buy-in, encouraging a higher level of commitment and engendering a willingness to participate in all of the phases of a project’s development. Ultimately, such involvement leads to motivation, and the scrum team should thus be motivated to participate when changes or a new direction are needed to achieve the goals defined for a sprint or product release.

Question: How do you ensure that the scrum team has access to a project’s stakeholders?

Answer: There is no predefined way to ensure access to stakeholders. All that can be done is to encourage stakeholders to engage in meaningful communication by being transparent and helpful. Sprint demos are a useful mechanism for this, often promoting better relationships between different departments and business units — improving a scrum team’s access to their projects’ stakeholders.

Question: How do you handle team members that “lead” standups, turning the event into a reporting session for themselves?

Answer: Although there are not officially any leadership roles within a scrum team, someone is likely to assume that role. This might happen because of his or her (technical) expertise, communication skills, or level of engagement. It’s important, however, that this does not result in other team members reporting to this person. As a Scrum Master, I must therefore be vigilant and intervene if necessary to ensure team members communicate — during standups or otherwise — as required by scrum.

Question: How do you approach standups with distributed teams?

Answer: Standups with distributed teams are not much different from standups with colocated teams — except that sharing board activity may require video conferencing when the team is working with offline boards that mirror each other.

If you are using task management or planning software like JIRA (or any other cloud-based application), board updates are generally easy for each team member to follow on-screen. With such online software in place, a Skype call or Google Hangout may suffice.

Question: How do you make an immature team into a mature team?

Answer: First measure the current maturity of the team. Are they self-managed & cross-functional?

Getting to maturity:

• Takes time, growth is not instant, and you can be productive without having full maturity so rely on the current stage of maturity as you move in the Agile journey.
• Culture follows structure.
• Leaders go first – support and guide the rest of the team.
• The holistic evolution/maturity of the weakest link in the team’s maturity.

Tactics:

• Focus on people: Trust (Scrum Values + Pillars).
• Release control (loose grip to drive fast).
• Embody the values.
• Do the hard work.
• Grow together (stable teams).

Question: What would your response be to out-of-the-box solutions?

Answer: I think there are some defaults that are good to start with especially with new teams, but over time each team is going to look different and implement Agile differently and this has to be respected. What works for one team is not the same as for another team.

There is a foundational understanding of Agile, especially with regard to values and principles that needs to be established, but after that what gets built on top of that is different.

Question: How would you hit the ground running?

Answer:

• Observe the team. Sit with them and spend time with the team, but also the individuals on the team beginning with the PO and then with key stakeholders.
• Establish what metrics they are using to measure their progress.
• Based on my observations of the team, then craft together a continuous improvement plan that I would confirm with the PO of the team which I would start to execute as soon as possible.
• This would essentially be some kind of high-performance tree-like map that identified the next steps for high performance and ideally, the team would be empowered to choose what to work on next.
• From there, the coaching, mentoring, teaching, and facilitation would kick into gear. I would also use the agile maturity model as some kind of guide/input to that process.

Question: What aspect of your current role do you enjoy/motivates you?

Answer: I enjoy the leadership aspect of my role, focusing on delivery and not just knocking out tickets on the board. So, the leadership aspect of the team. I was really encouraged by the new Lead Engineer when he came on board and gave me some feedback. 

1. The team has so much synergy, it is as though they don’t need to communicate with each other in order to communicate.
2. The team is further advanced in Adopting Agile principles and values than any team he has worked on and he has to catch up to the team, rather than the other way around.
3. You have done all of the hard work in laying the foundations for the team, so I’m 1 month in and I’m still trying to figure out what value I bring to the team as a Lead Engineer. 

I do enjoy building products and facilitating conversations between different roles that are involved in delivery – stakeholders, engineers, analysts, end-users, product owners, etc… I’m good at that. That’s feedback from the stakeholders, not me talking about myself. I have carried the hat of PO, BA before, so I do enjoy being in a delivery role which I think is a good background for a Coach.

Question: How could you determine the success of Agile in an organization?

Answer: There are no universally agreed-upon metrics of indicators to measure that Agile is working. Every company or team should create their own definition of success based on the challenges that they are trying to solve with Agile. Here are some indicators to consider:

• Product increments meet client needs resulting in increasing product metrics—higher retention rates, better conversion rates, increased lifetime value, etc.
• Increased software quality. Fewer bugs, technical debt, etc.
• More effective allocation of resources on high-value products.
• Team velocity is increasing to new plateaus in the beginning.
• Stakeholders more readily participate in agile meetings, especially the sprint demo.
• Team members are happier and refer their friends to open positions in the company.

Question: Should the Scrum team be involved in the product discovery process? Why?

Answer: There are a few reasons why the scrum team should be involved in the product discovery process:

• Developers will be able to provide feedback on epics and user stories, which are technically not viable.
• The product owner and scrum team members will develop a common understanding of the market problem and client needs.
• This will foster a sense of ownership amongst the team members, which in turn increases motivation.

Question: As a Scrum Master, how do you ensure that the ‘Transparency, Inspection and Adaptation’ Scrum Pillars are being implemented by the team?

Answer: Scrum prescribes four formal events for inspection and adaptation and as a Scrum Master you should attend the events and ensure the team is following the ‘Transparency, Inspect and Adapt’ processes: 

• Sprint Planning
  • Inspect the average Team Velocity over the previous 3 or 4 Sprints, ensure that the velocities have been Transparent to the team, and ensure that the team Adapt the Velocity to be used for planning the Sprint.
  • Inspect the Product Backlog (PB) and ensure that it is up to date, that it is Transparent to all stakeholders and that the team Adapts the PBI estimates if necessary.
• Daily Scrum
  • Inspect the Team Board and Adapt the plan for the next day ensuring changes are Transparent to all the team.
  • Inspect the Impediments Board and Adapt plans to resolve impediments if necessary
• Sprint Review
  • Inspect the increment and adapt the Product Backlog if necessary making sure that any changes are Transparent to all stakeholders.
  • Inspect the Release Plan and Adapt it if necessary making sure that any changes are Transparent to all stakeholders
• Sprint Retrospective
  • Inspect the process that has been followed and make plans to Adapt the process if necessary making sure that any changes are Transparent to all team members.

Question: Can a Product Owner be the Scrum Master for a team?

Answer: No, The Product Owner should never act in the Scrum Master role. These two roles have conflicting goals and should not be merged.

Disadvantages: There is a huge conflict of interest because the Scrum Master and Product Owner roles have conflicting goals. The Scrum Master should never be responsible for delivery; that is the Product Owner’s main goal. It’s a conflict between business needs and team self-awareness. It’s about balancing long-term versus short-term improvements and results.

Result: In most cases, the role of the Scrum Master is neglected and the Product Owner controls everything. Such a team usually lacks any deep Scrum understanding and self-organization. All scrum ceremonies will be more of a status reporting meeting.

Question: What is your experience with reporting and metrics?

Answer: Ability to understand and guide leadership in setting relevant metrics that are aligned with the objectives of the product.

Basic understanding of Agile Metrics, such as percentage of tasks completed, percentage of work accepted, Story Cycle Time, Defect Density, code coverage, team velocity, etc.)

Ability to explain the difference between a BurnUp and a BurnDown

A basic understanding of tools used to develop and deliver such metrics – the use of a scrum board, reporting dashboards, and tools (JIRA, VersionOne, etc.)

Question: How do you help your teams continuously improve and reach their product/sprint goals?

Answer: Guiding, facilitating, and following up on action items for removing impediments and dependencies

Guiding and facilitating the development and implementation of team working agreements, e.g. acceptance criteria, the definition of ready and definition of done, etc.

Encouraging and facilitating the team to learn Agile development best practices such as Test-Driven Development (TDD), pair programming, etc.

Question: As a facilitator, how do I prepare for a workshop?

Answer: The following facilitator activities are required when preparing for a workshop:

Identify the Workshop Owner – Each workshop must have an owner; the person who needs the group decisions.  For example, for a requirements gathering workshop, the owner would most likely be the Product Owner.

Establish the Workshop Objectives – You can treat a workshop like a mini product development; the Vision is the overall reason for the workshop; the Objectives are the first decomposition of the Vision.  For example:

The Vision: To decide which products to promote

The Objectives:

• Decide the products in scope
• Evaluate the relative value of the products
• Establish a prioritized list of products to promote 

Establish the Participants – The Workshop Owner should give a list of required workshop participants and/or direct the facilitator to a person who can provide that information

Establish by when the workshop must be run – All decisions are time-sensitive.  It may be that some proposed participants may not be available at specific times.  The date and time of the workshop must be chosen to be within the cut-off date and to maximize the number of proposed participants

Establish the type of workshop to be run – Workshops can be run as participants sitting around a horseshoe-shaped table to an ‘Open Space’ where participants are free to roam a room with separate areas for discussion on specific topics.

Arrange the workshop venue – A workshop venue must be chosen and booked to suit the number of proposed participants and the workshop type

Establish any pre-workshop participant reading materials – It may be useful for proposed participants to have some information pertinent to the workshop before the workshop begins.  Although you, as a facilitator, will give them access to these materials, do not expect every participant to have read them!

Invite the participants to the workshop – Send invitations to the proposed participants with the following details:

• The reason for the workshop
• The Workshop Owner
• The workshop Objectives
• The date, time, and venue for the workshop
• The proposed participants; this may be the distribution list on the email; it gives proposed participants to suggest other participants and/or to suggest replacements for themselves
• Arrange for refreshments to be available
• Prepare the workshop space
• Point of Process

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/.