Scrum Master Interview Questions

Here's a list of top, expert-curated list of Scrum Master interview questions and answers which will help you competently crack interviews related to Scrum Master or Agile Coach. With the drafted answers, you can confidently face questions related to job positions like Scrum Project Manager, Technical Scrum Master, Senior Scrum Master, SAFe Scrum Master, and Scrum Master - Senior IT Program Manager. Prepare well with these Scrum Master interview questions and answers and ace your next interview at organizations like Cognizant, Accenture, Wipro, HCL, Infosys, & JPMorgan Chase.

  • 4.5 Rating
  • 31 Question(s)
  • 40 Mins of Read
  • 7654 Reader(s)


As a Scrum Master, one of the responsibilities is to help the team pulling up the backlog for a sprint which is already prioritized and pulling items which are placed on the top (sorted as per the priority). Once, the team is able to identify items that can add value from the pile of requirements, the Scrum Master can help them (Product Owner + Development Team) to convert them into good user stories (if it is not already).

A good user story is one which includes a description and has acceptance criteria defined. It should be a piece which can be delivered in a sprint and entails minimum dependencies. The team should be able to develop and test within the boundaries of the sprint along with providing the estimates. In short, good user stories follow the INVEST principle.


Independent - Reduced dependencies

Negotiable - Describes the functionality, can be negotiated between the Team and PO

Valuable - Provides value to the customer

Estimable - Too big or too vague = not estimable

Small - Can be done in a Sprint by the team

Testable - Good acceptance criteria

The scrum master can help the team in creating good user stories during the backlog refinement or sprint planning so that the team can pick them up for the commitment.

For a Scrum Master, it is important to understand the pulse of the team. If there’s a member in your team who takes the meetings as useless, it’s time to know why he/she is adopting such a behavior. The focus should be on the behavior rather than the individual, the Scrum Master should try to talk to the team member individually by asking open-ended questions to find out the reason for not attending the meeting. Certainly, there is a need to understand the cause of this behavior and try to explain the importance of the planning meeting (Scrum ceremonies).

In Scrum, each individual is important, it is like wheels of a truck, any wheel gets dealigned or malfunctioned, the complete vehicle suffers. Hence, the need to explain the impact of not having his presence in the planning meeting and its impact on the entire team arises. Even the team can start to feel this imbalance. If it is still not resolved, the Scrum Master can set up a meeting with his reporting manager to talk about the concern and look out for ways to help the team member and the team.

Agile talks about continuous interaction and collaboration between the scrum team. The team members should NOT wait until the next daily scrum to ask for help, in this way, they are introducing delays in the process which will impact the overall sprint goal. If there is an obstacle, it should be raised then and there. In a sprint planning, the team commits the sprint items as per their capacity.

For example, I have 50 hours of committed work but due to some blocker, I got stuck. Now, if I wait to talk about it the next day or next daily scrum, I am wasting my workable hours which could have been resolved by raising it then and there. The question also specifically calls out for the ‘experienced team members’ which means if the experienced members are resorting to waiting, then it sends the wrong message to other team members. Such behavior within the team also portrays hidden conflicts or team members hesitating to talk. The Scrum Master should help the team in understanding the importance of real-time discussions, and promote healthy dialogue between the scrum team. Even the Scrum Master can come up with some team-building activities to make the team collaborate more efficiently.

During the early phases of the product development lifecycle, it really helps if the scrum team is made part of the discovery process. You should understand that agile talks about the early involvement of the teams with the stakeholders so that both parties are on the same page in regard to the development. Let’s look at some of the advantages of early involvement:

  • The development teams identify the technical challenges in implementation early in the process, hence, can help in reforming the requirements along with the customer.
  • The team along with the product owner also start sharing a common understanding of what is to be built. Sometimes, the teams can help the product owner in identifying the requirements which might have been missed.
  • They share a mutual understanding of what is to be built. It also helps the teams to stay committed and confident, they tend to build an ownership of their work and most importantly it boosts up the morale of the team.

To facilitate this, the scrum master can start involving the teams in early discussion of the product where the requirements are still at a high level. The team together with the product owner can build up the product backlog.

The teams working on a product need to know the integrity of the project and the customer. The product owner should help the team understand ‘Why are we building it?’, ‘What purpose is it going to serve?’.

Such questions help the team to understand their customer. The product owner has to convey the value that will be added if the product is delivered on time. Conversing the market situation helps teams to understand how the product management works and the criticality for time to market. It also helps to steer the team in a different direction at the end of every Sprint, the product owner can help the team in understanding how the customer is going to consume the product.

Sprint planning is a collective effort including a Scrum Master, who facilitates the meeting, a Product Owner, who makes clear the specifics of the product backlog items and their corresponding acceptance criteria, and the complete development team, who outline the work and effort necessary to meet their sprint goal. The scrum master can help the team by:

  • Time-boxing the activity
  • Making the team stay focused on the intention of the meeting
  • Facilitating and Resolving(if required) any deadlocks in the discussion
  • Can help them to commit the right amount of work, as per their available capacity.
  • To make sure that the team is invested and asking the right questions.

To accomplish this, the scrum master can help the team understand the definition of being ready and the process to create meaningful stories. Also, as discussed earlier in the questionnaire, it is important to get the team to participate in the early discovery process to make them understand the product. The stories should be created as a collaborative effort between the development team and the product owner, this creates a shared understanding of the common goal.

Estimating in man-hours is one of the most prevalent methods for assessing teamwork. While man-hours are easy to understand, there are a few big disadvantages to this method:

  • Few tasks are hard to estimate precisely, e.g. the legacy work
  • If one team member provides the estimate but another completes the task, the estimate becomes worthless.
  • The time needed to complete a task will vary based on a developer’s level of experience.
  • Teams usually misjudge impediments they might face and contemplate only the best-case state.

The advantages of estimating user stories in points can be – There is no correlation with the skills and experience of the estimator, story points do not depend on who is doing the story. As the story points are a measurement of relative sizes, and the size of the story cannot be changed by external pressure, the team members can estimate more accurately. Story Points invites collaboration as team behavior becomes prominent over individuals. Using planning poker to estimate story points brings the team together.  It acts as a team building activity as teams share, constructively criticize each other, debate and have fun playing poker cards to come to a consensus on estimates.

User story

Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. – Mike Cohn

During the early product discussions, the team talks about the requirements and capture those in the form of user stories. As product backlog always live, never stays frozen. Hence, if someone feels there’s a missing requirement or something that can add value to the client, they can add it up as a user story in the backlog. There is no rule or guideline stating that only the product owner has to write the stories. People writing the story should understand what exactly it means and how to write it, as there is a set format.

Writing user stories also gives a sense of ownership to the team members and they can connect easily if they are involved in the writing process. User stories are written all through Agile development. Typically a story-writing workshop is held near the start of the agile project. Each person on the team contributes with the objective of crafting a product backlog that completely calls out the functionality to be added over the course of the project.

When the sprint is being planned, the team commits the sprint items as per the available capacity. To target the optimum execution, the team should ideally commit between 80% - 90% of the team’s total capacity, anything beyond that percentage will hinder the team’s performance. Bugs, refactoring, and research requires consistent attention in order to escape building-up technical debt.

Though the teams already have items to work on from the product owner, some of the teams set aside 25% of the capacity for this job. We also have a good practice which the teams can follow, 15-10-5 allocation of the scrum team’s capacity, which means, 15% of a team’s capacity to technical debt, 10% of a team’s capacity to defects, and 5% of a team’s capacity to exploratory work.If the team is able to follow these allocations, it will fulfill both the code quality and upkeep necessities of most software applications.

It is a good practice if followed sprint by sprint, but if for some reason the team is not able to do it in a particular sprint due to high priority delivery, it’s fine.

As part of a Scrum Master role, one of the responsibilities entail around helping and coaching the Product Owner. It is really critical for the Scrum roles to understand their role and function accordingly. If the product owner is assigning the user stories/tasks, it is the job of a scrum master to make the product owner realize the meaning of self-organization.

In the Scrum Guide, a partial definition of self-organizing is given as Scrum Teams are self-organizing. Self-organizing teams choose how to accomplish their work, rather than being directed by others outside the team.” Self-governance is one of the utmost motivators there is for people doing creative and problem-solving types of work. Assigning tasks to people is an implicit claim that the product owner knows better than the team, this not only passes on the wrong notion but it also lowers the morale of the team and at the same time defies the scrum values and Agile principle – “Point 5. Give them the environment and support they need, and trust them to get the job done.” And “Point 11. The best architectures, requirements, and designs emerge from self-organizing teams.”

Hence, the product owner is assigning work, the Scrum Master should intervene and help the Product Owner in understanding the true sense of working in a Scrum framework and refrain him/her to continue this practice.

One of the Agile Principles states “Business people and developers must work together daily throughout the project”. The stakeholders can join the daily scrum meeting but they can be mute spectators till the time scrum is not complete. The Scrum Master should encourage the stakeholders to join the meeting by making them understand that it will be worth their time.

The goal of the Daily Scrum is to know whether or not they will reach the Sprint Goal. If the stakeholders are joining the daily scrum, then they will get to know the updated picture of product development and can accordingly adjust their expectations. They get to know about the real issues that the team is facing, which helps both the parties. This event gives the opportunity to the development team to directly ask questions with the stakeholders. It not only promotes a platform for discussion but also provides early detection of risk for the stakeholders. But the Scrum Master should make sure that the inclusion of the stakeholders in the daily scrum is not converting the meeting into a status update. Although stakeholder presence is not mandatory, it doesn’t matter if they are there as a listener because it can facilitate the resolution of any impediments.

The sprint retrospective is an opportunity to inspect and adapt the process as it is a time to reflect on the process. It is needed that the full Scrum team attends. This includes all members of the development team (includes everyone who is designing, building, and testing the product), the Scrum Master, and the product owner. Since the Scrum Guide also states that the Scrum team = product owner + Scrum Master + development team, we can deduce that (officially at least) the product owner is allowed to attend the retrospective. This is the ideal scenario. However, sometimes, the teams might not wish to include the product owner as it might hinder their discussion. If there is a lack of trust between the product owner and the development team, or there is a low level of safety so that speaking candidly isn’t comfortable, perhaps the product owner should not attend until the Scrum Master can help coach those involved towards creating a safer, more trusting environment. Anyone else outside of the immediate scrum team, and particularly managers of team members, should not be invited to participate.

The retrospective format provided by Scrum Guide contains three items:

Sprint retrospective Model

  • What went well?
  • What didn’t?
  • Action Items to improve

This is the usual format that is being used by the Scrum teams. But after a while, it gets monotonous to use the same. And as each team is different, the same formula might not go well with all. There are many different retrospective ideas out in the Agile world, including distinctions and trimmings on the rudimentary questions and creative facilitation techniques.  Scrum Masters should develop a toolkit of retrospective techniques that they can use and adapt to their teams. Let’s look at a few:

  • Sail Boat - The idea is to draw a speedboat on a flip chart and ask the team, “If our team is this speedboat, what anchors are holding us back and keeping us from getting faster/better?” Then the team collects all their ideas on Post-Its, puts them below the boat and draws a line from the boat to the anchor.
  • Speed Car - This is a simple activity for helping the team to identify things that make them move faster, and things that slow them down.

There are several other ideas as well, like:

  • Liked, learned, lacked, longed for (4 L’s)
  • Starfish (small, large)
  • Stop, start, continue
  • Mad, sad, glad

Retrospectives don't finish when they're concluded. In fact, the toughest part has now been initiated: Following-up on your retrospective action plan. In a retrospective, one of the outcomes is the action items which the teams have identified to make their process or work environment much better (retrospective can touch base at different levels). If the action items identified during the last retrospective is not worked upon or gets lost during the course of the sprint, the team will start refraining from coming up with the points as they will not see any closure on the items. Hence, the Scrum Master should present the action items from the last retrospective and discuss the status of progress.

This gives a sense of satisfaction to the team that they are getting heard and the items are being tracked to closure. There are several ways of following up, for example,

Running the activity

Running the activity:

  1.   Open the list of action items (and their respective owners)
  2.   Update the status for each item on the list.
  3.  Add newly identified items

Each team can have a different tool for tracking their action items. Some examples: post-it on the team wall, a shared excel document, Trello, etc.

As the saying goes, “One size doesn’t fit all”. Same goes for Agile. All projects and products might or might not fit into the agile arena. In our case, it is working and we are actually reaping the benefits. Let me list out some areas where we see the difference:

Cases of Agile Working in your Organization with Success

  • Faster Time to Market - The idea of two-week delivery cycles and quarterly release cadences helped in quicker deliveries.
  • Feedback from real customers – Frequent collaboration with the clients helped the teams in building the right product rather than delivering at the end with surprises!
  • Prompt risk detection - By delivering early and getting feedback, we reduce the risk of building the wrong product. By focusing on architectural risk in the early sprints, we reduce the risk that we won’t have a solution that can be built in time, at least the team knows it early.
  • Improved Quality Stats – Quality is an integral part of the sprint in terms of code coverage, unit tests, peer reviews, etc.
  • Predictability – With the teams trying to stabilize the velocity, we could easily predict the capacity for the upcoming release.

Every Agile journey is different, hence their experience. Thus, it is important to identify the success factors to promote excellence.

As a Scrum Master, I will not accept this process as it is its sugar coating Waterfall in the name of Agile. Just converting the requirements into tickets will not suffice for the entry criteria of the user stories. The requirements should be finely broken down into finer pieces so that it can be consumed in sprint time. The conversion of stakeholder requirement into tickets should also follow the best practices in the industry like INVEST, 3Cs, etc. to help teams gain confidence into what is to be built.The focus should always be on delivering value to the customers, which requires keeping a health prioritized backlog. The organization adopting Agile use tools like Rally, Version 1, etc. to manage the product backlog and sprint backlog. Hence the requirements should be entered in the tools for the teams to pick.

Moreover, the scrum team should be involved early in the product discovery process so that all the parties involved have a shared understanding of what is to be built. This also helps in curating the requirements which are feasible and have pre-identified risks and challenges. Finally, the Scrum Master should help the teams to be agile and not just allow anti-patterns to grow.

Benefits of Good User Stories

The Product Owner is invested to conclude the value that the user story will deliver, enabling him or her to set the backlog as per the highest priority. When a user story is created, it carries some value (we have also learned about it in the INVEST model where V stands for Value). When the sprint is being planned, the team pulls up the highest priority item from the pile for commitment. If the team members are picking up tasks as per their comfort, the scrum master has to come in picture and coach the team. Even the product owner might pick up stories which are not adding value to the customers.

Hence, the story time or the sprint planning meeting should be addressed in the true sense, the scrum master should facilitate these meetings in a way that they stick to the intent of the meeting and come out with the valid outcomes. Both the team and the product owner has to focus on value delivery rather than ease of work. If the teams are involved early during the product discussion, these types of challenges can be minimized.

A user story represents a small piece of business value that a team can deliver in a sprint. Though traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally in three stages:

Structure of a Good User Story

  • Who are we building it for, who the user is? — As a <type of user>
  • What are we building, what is the intention? — I want <some goal or objective >
  • Why are we building it, what value it brings for the user.? — So that <benefit, value>

Well-formed stories will meet the criteria of Bill Wake's INVEST acronym:

A. Independent - Can the story stand-alone by itself?

B. Negotiable - Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.

C. Valuable - Users or customers get some value from the story.

D. Estimable - The team must be able to use them for planning.

E. Small - Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.

F. Testable - Can this story be tested and verified?


The entry criteria for any story in a sprint relies on Definition of Ready which involves creating clear criteria that a user story must meet before being committed into an upcoming iteration. In our scenario, the user story lacks final designs which clearly indicates that it is NOT ready to be picked up for the commitment. Also, in this scenario, the product owner agrees and pushes the team to commit. As per Agile, it is a wrong practice, BUT, it also depends on the team’s circumstances. If the past experience says that the design team has been delivering as promised on the timelines, or if the story is of high value to the client, in such cases the team can go ahead with the exception and commit the story.

However, this should not be made a regular practice as it would be a compromise with the principles and with the core essence of Scrum. The Scrum Master should look for such anti-patterns and help the team understand the importance of Definition of Ready.

It all depends on the team’s situation to go ahead with the exception or reject the same. Accepting stories which do not meet the ready definition increases the risk of completion and even impacts the teams’ efficiency.

The daily stand-up meeting helps the team to echo on the development of the team's commitment towards the sprint goal. Hence, all agile teams should meet on a regular interval so that everyone is talking the same language. The way of executing the standup can differ according to the size and experience level. Lets’ take up some scenarios:

Recommended Stand ups for All Teams

  • Small & Experienced – If the size is small with experienced members, the team can meet up over a quick break, they can even opt for a casual meeting.
  • Small & Less Experienced – Even though the size is small, the Scrum Master should prefer going through a formal standup as the team needs to understand the progress, they might need help with technicalities or business functionality, they also need to realize the values, principles and the discipline in the process.
  • Large Teams – Opting a casual approach might prove difficult with large teams, as for large teams formal meeting is required to provide guidance and clarity.
  • Distributed Teams – Your team is considered co-located when the developers and the primary stakeholders are all situated in the same workroom. Otherwise, your team is either geographically distributed or dispersed in some manner. In the case of distributed teams, since there is a constraint of location, the teams can use the ‘dial-in’ and conduct the daily scrum in an organized manner.

Approaching Standups with Distributed Teams

The daily standup meeting in agile remains the same, that is, 15 minutes, where the team meets, talks about the three questions. Any further discussion will be a part of the sidebar, that’s it! “For teams that share work between time zones, stand-up is a great time to pass the baton as the team which is coming online can pick up right where the other team had left off. And holding stand-up via video conference makes it easy to ask questions and get up to speed so everyone is off and running as soon as the meeting is done.” - Atlassian

This applies to all the Agile/Scrum teams whether they are co-located or distributed, the scrum events remain the same. With distributed teams, there is just a small difference – they use video conferencing for sprint board sharing (if no online tool is being used). But if the teams are using tools like Version 1 or Rally or any other tool, they can simply use a dial-in number to connect with each other. There are multiple platforms like Skype which can be used to bring together the teams. Here, the Scrum Master can come up with creative ways of working with distributed teams, like - coordinating across time zones, building a relationship when everybody is not in the same office, working together among different development cultures.

The meaning of ‘Kanban’ is a visual board, where ‘kan’ means visual and ‘ban’ means board. In Scrum, the sprint board works in Kanban manner. Let me pull up a draft board:

It is comprised of vertical swimlanes where each lane stands for a phase in the sprint execution. Horizontally, it contains the sprint items. Each vertical swimlane can be customized as per the product or project need. Usually, it has – Backlog, To Do, In-Progress, Done and Accepted as the header. Once the team has started working on an item, it will start flowing from one phase to another. If the item is blocked due to an impediment, then it will sit in that vertical till the time is resolved.

The scrum master has to help the team in a smooth flow of sprint items through continuous collaboration, discussion, and focused approach.

Kanban Board

The additional information to cover-up the Kanban can be:

  • Sprint timeline – Start date and the end date
  • Sprint Cadence - Pulse or rhythmical flow of scrum events
  • Definition of Ready – Entry criteria for the user stories
  • Definition of Done – Exit criteria for the user stories

You can even mention the metrics around the Kanban board. The Kanban board serves as an information radiator for the team and outside the team (stakeholders + management).

As mentioned in the earlier question, sprint retrospective is an opportunity to inspect and adapt the process. Thus, checking the team’s health at this meeting can be a good opportunity. The team should together this time look at the areas of improvement and talk about the overall health.

The Scrum Master can facilitate the health check through various tools, simple can be using a scale from 1-5 where 1 stands for awful and 5 for extraordinary. They can even use the TeamHealth Retrospective which is a powerful deep-dive strategic retrospective tool that focuses on the top areas that affect team performance and health.

To check the team health, the team can come up with the parameters to check on the health – Culture, Technical Practices, Quality, Backlog Visibility, and Team Collaboration. The team can have its own customized parameters and against those parameters, there will be some points to validate that parameter. The team, after discussion, gives a point on the scale of 1-10 to that parameter. The same goes for all the parameters. Once this activity is done, the tool will automatically generate a spider chart showing the areas that need improvement. The Scrum Master can coach and suggest the team on how to reach the 5 in the spider!

When the Scrum teams follow the same pattern of the retrospective sprint by sprint, it does induce weariness among the teams. The Scrum Master needs to be creative enough to try out different patterns, sometimes changing the location also works. Anything that happens regularly with the same format tends to create an uninteresting environment in the meetings.

As discussed in the earlier question, the scrum master can use different types of retrospectives to create a fun introspecting atmosphere. Some of the teams opt to go out for lunch and have a discussion over there, it not only helps to collaborate but also provides a safe environment to discuss. Or you can use a different room. While creating a conducive environment to reduce the boredom, the Scrum Master has to make sure that the essence of a retrospective is not lost. The intent should be the same even when you are using different patterns.

To make the retrospective effective, the team should identify the action items. This gives a platform to the team to start a conversation, but only identifying will not serve the purpose. The action items should be targeted for closure and scrum master should take steps in realizing this goal. For every action item, there should be an owner, teams should refrain from assigning multiple owners to a single item as the idea of ownership dilutes. The scrum master should manage the repository of action items on a tool or an excel which is accessible to all the team members. Having a backlog of action items also helps as then the team can actually prioritize.

In the retrospective meeting, the team should go through the items from the last retrospective and talk about its status, in that way everyone can keep track of where they are and what more is required to achieve the goal of closure. Few organizations use retrospective tracker where the action items are categorized into – priority, ownership, status, description, identified on, type. Working on the actions items gives the team a boost that they are moving forward towards improvement and also it enhances the sense of ownership.

Though Scrum mentions the Scrum Master role as the person enforcing the process, it is important to understand what exactly does the enforcement mean and what its boundaries are.

Enforcement does NOT mean forcing the team to follow the process, but it implies putting in practice the core entities of the Scrum to help the teams be successful. The Scrum Master is the facilitator helping the teams reach their goal. During facilitation, the Scrum Master will use Scrum practices and would encourage the team to follow the scrum values.

Again, it is important to mark that we are talking about encouragement and not forcing. It is not a role similar to the project manager but this role will help the teams to bring their blockers to closure, it will be a collaborative effort and not a directive one. From time to time, the scrum master will try to show the benefits of adopting the processes and help the team acquire an understanding on the scrum processes which is like showing the right path but it is up to the team if they want to walk through it. The scrum master will also be acting as a coach for the team to help with outshine in the agile journey and be successful.

Every organization opting for Agile creates a model to assess the maturity at different levels. It helps them stay focused and goal-oriented. It is an assessment of an organization’s suitability for agile practices, providing an idea of the necessary steps for an organization that decided to become a learning organization. The metric is based on the initial collection of data as to what the current situation is and what is the desired level. Hence, the parameters involving the assessment can be different for different organizations.

In our case, the focus was on:

  • Ability to accept change
  • Team communication
  • Team Location
  • Delivery Regularity
  • Planning Methodology
  • Testing
  • Business Value Focus
  • Technical Excellence


Each of the pointers mentioned had sub-details to analyze and assign an appropriate number. The assessment was done on a regular interval to check if the teams are reaching the milestones set in agreement with the management (agile focused). It also helps in identifying areas which need immediate attention. The team can swarm together to improve that item.

The team’s performance is not just related to a single event or a reason but there can be different scenarios that might be building up that situation. A good scrum master has to identify those patterns and look out for ways to minimize it. Let’s look at a few of the situations that might lead up to lowering the team’s performance:

Situations that may lower a team performance

  • Planned Leaves or Holidays – The sprint commitment is directly proportional to the total available capacity of the team. If there are leaves or holidays, the commitment will go less and hence lowering the velocity.
  • Legacy product – In case the code has been written long back with no documentation, the new members struggle to figure out things.
  • New hire – Onboarding a new associate will impact the sprint commitments as the member is new and needs time to be brought to speed.
  • Resignation – If the team members are leaving, it might take some time to fill up the gap.
  • Experience – If the team comprises of experienced team members along with new one, then the level of seniority might hinder the team formation.

There can be many reasons, but the scrum master should keep their eyes open for any such patterns and try to help the teams get back to track through coaching and adoption of best practices.

Definitiion of Ready

The product backlog contains a list of items to be worked upon by the team but it is important to check if the items are in a ready state to be picked up in a sprint. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story or PBI. The Definition of Ready can differ from product to product or from team to team. It is a working agreement between the team and the Product Owner on what readiness means. Let’s look at some of the parameters that can go in defining the Ready state:

Definition of Ready for a User Story

  1. The PBI is in “Approved”, or equivalent, state for the team to pick it up for development
  2. User Story dependencies identified
  3. Acceptance criteria exist and are understood by the team
  4. Acceptance criteria have sufficient details on the features to be developed and tested by the team
  5. Performance criteria have been provided, where appropriate, and are understood by the team
  6. The PBI has been written in the
  7. Actor->Action->Outcome format
  8. UX wireframes exist, where appropriate, and are understood by the team
  9. Performance criteria identified, where appropriate
  10. Team has a good idea of what it will mean to Demo the User Story

One of the advantages of working in Agile is the clear backlog visibility at least for three sprints. If the product owner is adding up the items in the backlog, then it might be he or she is getting ideas and they are just parking aside on the backlog. That doesn’t mean that the team has to work on all the ideas. A product backlog can have a list of items to be accomplished, but the team will only focus on the high priority items which can add value to the client.

Also, here, the role of a scrum master can come handy, this role can help the product owner understand how to arrange the backlog, and how to create items that can be consumed by the teams. The scrum master can explain different prioritization techniques that can be used for keeping the backlog sorted. But the scrum team is not expected to pull up everything that is on the backlog. One of the roles of the Scrum Master is to coach the product owner on how they can best converse their intent to the Development Team. There are many techniques to accomplish this, such as product visioning, product road mapping or release planning.

The focus of the team should be on delivering value to the customer. It is not only the responsibility of the team but also it is important from the organization perspective. Each story is built on the concept of priority and value added to the customer. If the team is able to bring value through frequent deliveries and product increment, then the client will be happy. The client satisfaction can also be one of the metrics to measure, if the client is able to realize value, it will be worth their money.

Another one can be, focus on minimizing the technical debt, once the product development starts, it is important to do the maintenance work from time to time to ensure the performance of the product, no one wants a dead code in the system. Bugs, refactoring, and research also requires regular attention to avoid building-up technical debt. Any metrics which cannot relate to the value delivered should be avoided in such scenarios as they portray a different picture, e.g, though velocity variance is a good metric to track if I relate to value delivery it won’t work well.

Hence, the focus should always be on value delivery, and it should be the prime goal.


A Scrum Master is a person who supports Scrum and is responsible for promoting Scrum. Rooted in leadership roles, a Scrum Master has to make sure that everyone understands the Scrum theory, practices, rules and values. They hold the scrum framework together, easing the process for the organisation, Scrum team, and Product Owner. It is the responsibility of a Scrum Master to ensure that the Scrum team understands the scope, goals and product domains best as possible. Also, they have to find effective techniques to manage the Product Backlog

According to, the average base pay for a Scrum Master is $93,285 per year. A few of these companies are Google, Yahoo, Microsoft, Facebook, Adobe, Nokia, etc.

If you are determined to ace your next interview as a Scrum Master, these Scrum Master interview questions and answers will fast-track your career. To relieve you of the worry and burden of preparation for your upcoming interviews, we have compiled the above list of interview questions for Scrum Master with answers prepared by industry experts. Being well versed with these commonly asked Scrum Master interview questions will be your very first step towards a promising career as an Agile Coach/Scrum Master.

You can opt for various job profiles after being certified as a Scrum Master. A few are listed below:

  • Scrum Master
  • Senior Scrum Master
  • Agile Scrum Master
  • Agile Project Manager
  • Product Manager
  • Mentor
  • Product Owner
  • Scrum Coach
  • Coach Scrum Master

If you wish to build a career as a Scrum Master, you can learn more about Scrum Master certifications from the best training available.

Crack your Scrum Master interview with ease and confidence!

Read More