Scrum Interview Questions | Eklavya Online

Scrum Interview Questions

Cancellation of a sprint is generally a rare case as there are losses associated with it. Cancellation seems viable only in case of the Sprint Goal is no more valid and changes cannot be finished in the given sprint. A Sprint can be canceled before the Sprint time box ends & only the Product Owner can cancel the sprint. In case of cancellation, the DONE PBI’s (PBI = Product Backlog Items) are marked done and remaining goes back to PB. After this we plan for new sprint.

Issues: This can be a little impractical in case if there are multiple teams working together on the same Product and all the teams are dependent on each other. However, the situation sensitivity needs to be exercised in such cases.

The perspective for Customer:

When the customer takes a lookout in the market as for going with which technique for Software Development process, Agile Methodology stands perfectly for the need and outreach for the Customers. The Agile Methodology is more responsive to the customer’s request. Not only it gives the customer high valued features but also delivers more quickly with short cycles.

The Benefit for the development team:

Agile has a great role in making a good working environment. It makes the work process very smooth and makes the team enjoy development work. This helps to generate more good output. With Agile Methodology, their work is valued and more quality product is delivered. It also helps in reducing non-productive work.

The Benefits for Scrum Master:

As a Scrum Master, one needs to have good knowledge of Agile Methodology and how to implement the method into Scrum Framework. Agile gives a process for Scrum Master by virtue of which they can easily plan and track task in daily meetings. Agile gives the Scrum Master a good sense of approach and awareness towards the project state and status. The Agile Method also helps the Scrum Master to react to blockages quickly and address them.

The Benefits for Product Owner:

As a product owner, one predicts to have a good sense of approach for the work process so as to get a product of high values. The Agile development method the product owner to develop work aligns with customer needs. As it gives a product of high quality and highest possible values, it gives a good scope to them for a good approach.

The Perspective for Vendor:

As a vendor, with the help of Agile Methodology, one gets focused development on high-value features with increased efficiency It also helps them to reduce wastage and decreases the overhead.

Typical Scrum Master Sprint anti-patterns are below. Any of these behaviors will impede the team’s productivity. It is the Scrum Master’s obligation to prevent them from manifesting themselves. Some of the Scrum Master anti-patterns are:

Keeping the Scrum team dependent: In this scenario, the Scrum Master pampers the team to a level that keeps the team dependent on his or her services: organizing meetings, purchasing stickies and sharpies, taking notes, updating Jira—you get the idea of this service level. More critical, however, is when the Scrum Master decides to keep the team in the dark about principles and practices to secure his or her job. This behavior is only a small step away from the dark side.
Flow disruption: The Scrum Master allows stakeholders to disrupt the workflow of the Development Team during the Sprint. There are several possibilities on how stakeholders can interrupt the flow of the team during a Sprint:
The Scrum Master has a laissez-faire policy regarding access to the Development Team.
The Scrum Master does not object when management invites engineers to random meetings as subject matter experts.
Lastly, the Scrum Master allows either the stakeholders or managers to turn the daily Scrum into a reporting session.
Lack of support: The Scrum Master does not support team members who need help with a task. Development teams often create tasks an engineer can finish within a day. However, if someone struggles with a task for more than two days without voicing that they need support, the Scrum Master should address the issue. Importantly, this is also the reason for marking tasks on a physical board with red dots each day if they haven’t been moved on to the next column.
Turning a blind eye to micromanagement: The Scrum Master does not prevent the Product Owner – or anyone else – from assigning tasks to engineers. The Development Team normally organizes itself without external intervention. And the Scrum Master should act as the shield of the team in this respect.
: The Scrum Master sweeps conflict and problems under the rug by not using Sprint Retrospectives to address those openly. This behavior is often a sign of bowing to politics and instead of using manipulation to meet organizational requirements that are opposing Scrum values and principles. If the organization values its underlings for following the ‘rules’ instead of speaking the truth why would you run Retrospectives in the first place? A ‘Scrum Master’ participating in cargo-cult Scrum is again a supervisor than an agile practitioner.

It helps in rapid & iterative delivery of useful software hence giving customer the competitive advantage.
Due to self-organization and empowerment given to technical teams innovation is exercised comparatively more
The profitability increases due to early delivery
If the market is not conducive to the product – we get early feedback and the business can take a decision to No-Go or Pivot or change the product direction.
Face to face conversation reduces documentation overheads and delays and also foster quality

An MVP is set of minimum requirements or features with which it looks like the product if shipped can be used by the users well and they feel the major value is delivered. However MMP is the minimal set of a requirement that is ready to be shipped to market and can be marketed that guarantees the usefulness to the customer. MMP is fully realized version however MVP may the one which is not fully ready for market but estimated to be valuable if completed and released.

Example MMP: www.redbus.com released the first version without capability of billing and disbursal of tickets. The caveat here is you must validate that this minimum feature product solves few major problems for the users and they feel it’s good for us. So with Red bus even without payment capability, the users were able to see the buses details and send info about with bus they want to book and bus operators used to call them and reserve seats. SO the major problem of travel and communication hassle was solved.

MVP: Imagine Red bus is ready with the code and can be released however they do not have the real Bus data that can be used by users for booking then they have an MVP but not MMP.

Waterfall Model was the first process model to be introduced. The Waterfall Model is a linear sequential life cycle model which is very easy to understand and use. The key principle on which the waterfall model emphasizes is only after the completion of one phase, the working team are allowed to begin with another phase. The Waterfall model is mostly preferred for small projects and there are no uncertain requirements.

Waterfall Model has six different phases for product development. And every phase must be and should be completed before starting with another phase. So, let’s dive in and read different stages of Waterfall Model Suggests.
Requirement Analysis:

The very first phase of the Waterfall model emphasizes on the collection of things which are required for the software development and then documenting it for further use.

System Design:

This very phase of the waterfall model studies the requirement and with the help of that system design is prepared. This phase also helps to specify the hardware and software parts and helps to plan the overall architecture.

Implementation:

In the implementation phase of the waterfall model, the system is developed with small programs called units who are later integrated with the further process of software development.

Integration and Testing:

In this phase of the waterfall model, the units which are developed in the Implementation phase are further Integrated after testing of each individual unit. After all the units are integrated into the system, final testing is done to check if the work processed is up to the expected parameters.

Deployment :

Once all kind of testing is done and if the results are satisfactory, the system is further deployed in the customer environment for the service and its use.

Maintenance:

To cope up with the client environment, the maintenance phase is their who provide regular feedback and help to fix the issues and patches which come up with the product and software.

There are two principal reasons why a Scrum Team should be involved in the product discovery process as early as possible:

The sooner engineers participate in the product discovery process, the lesser the chances solutions will be pursued that are technically not viable or would not result in a return on investment.
Involving a Scrum Team early on ensures that the team and its Product Owner develop a shared understanding and ownership of what will be built.
This helps significantly with allocating resources to the right issues, maximizing value for the customer, and mitigating investment risk by maximizing the amount of low-value work not done.

Involving the Development Team members early in the process ensures their buy-in, and the team’s willingness to participate in all phases of a product’s development. This motivates the team to participate when making changes necessary to accomplish the Sprint Goals defined for each Sprint or product release.

Only the immediate members of a Scrum Team — Development Team members, Product Owner, and Scrum Master — should participate in that team’s Sprint Retrospectives.

Especially noteworthy is that the line-managers of a Scrum Team’s members not be present. Also, they should not be allowed access to the minutes of any Sprint Retrospective.

Apart from Sprints during which there are critical and urgent tasks to address (such as fixing a problem that has taken the website offline), a good rule of thumb is a 15-10-5 allocation of a Scrum Team’s capacity to refactoring, fixing, and research. Specifically, this means dedicating:

15% of a team’s capacity to technical debt and refactoring,
10% of a team’s capacity to bugs, and
5% of a team’s capacity to explorative spikes (when potentially helpful).
A Development Team may, of course, deviate from this rule of thumb depending on the context. Generally, consistently making these allocations will satisfy both the code quality and maintenance requirements of most software applications and build trust among stakeholders regarding the Scrum Team’s capability to deliver valuable product Increments.

When impeded, members of a Scrum Team should never need to wait, neither for a Daily Scrum nor any other event, to ask for help. A team waiting to ask for help is a team delaying progress. If the more experienced members of a Scrum Team are waiting for the next Daily Scrum before either asking for help or themselves dealing with an impediment, the Scrum Master has team-building work to do.

This question is meant to encourage an exchange of ideas about, and lessons learned when overcoming resistance to Scrum within an organization. Familiarity with agile failure patterns that are common to many organizations will demonstrate your candidate’s experience. (We have published a list of several agile failure patterns.)

Your candidate should also be familiar with the particular challenge middle managers face in any transition to agile practices. Moving from a command-and-control style (i.e. managing people and telling them what to do) to a servant-leadership style — thus abandoning Taylor’s principles — is not for everyone

If a Scrum Team is exhibiting a volatile velocity, consistently failing to meet their forecasts, it suggests that velocity is being used as the prevalent metric for measuring that team’s progress.

Your candidate should mention this, and talk about the notoriety of ‘velocity’ as the industry’s most prevalent metric for measuring a team’s progress. They should further be able to explain why velocity is altogether a doubtful agile metric and point out that quantitative metrics are not ideally suited to measuring a team’s progress in mastering Scrum.

There are many factors that make a Scrum Team’s velocity volatile:

New team members being onboarded;
Experienced members leaving the team;
The team working in uncharted territory;
The team working with legacy code, probably undocumented;
The team running into unexpected technical debt;
Holidays and sick leave reducing the team’s capacity;
An executive intervention changing a Sprint’s scope; and
The team addressing unplanned priority bugs.
Another common cause for a Scrum Team to consistently fail in meeting their forecasts is that the team’s Product Backlog items are being poorly prepared, thus making the work items difficult for the team to estimate. Conversely, the projects being given the team might suffer from poorly documented legacy code, excessive technical debt, or just too much buggy and poorly written code — all of which make estimation a gamble.

Your candidate should not align themselves with the fallacy that a team’s adoption of Scrum is working only because a Scrum Team’s forecasts and velocity are aligned. Cooking the agile books is easy to do!

There are three main artifacts in SCRUM:

Product Backlog
Sprint Backlog
Product Increment

Estimating user stories in person-hours is rarely a good idea. It intentionally diverts the emphasis away from the true purpose of the estimation process: to create a shared understanding of the task ahead among all members of the Scrum Team. Ergo, the estimate itself is just a byproduct.

Estimating is often tricky when:

Legacy software is involved,
A team is facing significant technical debt, or
A team is composed of mostly junior members.
Hence story points are much better suited to estimating than man-hours in all situations, but especially in tricky situations, because they reflect both the complexity of the task and the effort required to complete it.

Using person-hours instead of story points typically shifts the focus from value creation for customers to the more traditional project management of costs and budgeting, effectively imposing a waterfall process. Also, estimating in person-hours suggests an unmerited level of precision.

A good candidate would mention the ongoing discussion in the agile community as to whether estimations are useful in general. They would also likely point to the ‘no estimates’ concept.

Scrum is a simple iterative framework which comprises of 3 roles, 4 events, 3 artifacts and few rules which believe in delivery of product features or solution in iterative, incremental manner.
The iteration is called as SPRINT and is mostly of a month or less where teams deliver a potentially releasable solution at the end to the user/customer.
Scrum believes in ownership culture and gives Team the freedom of choosing how much to plan to deliver in a sprint however the What is decided by Product Owner.

Estimation can be done using any available estimation techniques such as Function Points, Wideband Delphi etc. and Scrum has no recommendation for this. However a relative estimation technique like Planning Poker estimation has been widely used across multiple companies and is very popular.

Early & continuous feedback which fosters inspect & adapt
Early delivery to markets
Increases communication between business and implementer reducing the scope for defects
Technology and business are aligned and hence cost reduction

A Scrum Master plays a very key, optimized and conclusive role for the working of Scrum Framework. The task and goal of Scrum Master are very diversified right from as the leader of Scrum teams to being the interface between the product owners and product developers. The position of Scrum Master is exclusive yet its practice and influence is extremely broad in use. So here are the following roles a Scrum Master plays in an organisation for Implementation of Scrum Framework.

Responsibilities of an effective Scrum Master:

Manage the Project Development and Implement the practices of Scrum

Keeping an eye on every track of the work process

Implementing Agile Development practices

This question revisits the previous. Again, your candidate should focus on explaining why involving the Scrum Team early in the product discovery process is beneficial for both the Product Owner and the organization.

Additionally, Scrum Masters can effectively support Product Owners by ensuring that the Product Backlog refinement process is continuous and of a high value regarding the Product Backlog. “Garbage in, garbage out“ does apply to Scrum. Essentially, the Scrum Team either wins together or loses together.

This question is an invitation to the candidate to share lessons learned from the successful application of metrics to help a Scrum Team improve continuously.

Suitable agile metrics follow three rules:

The first rule of tracking meaningful metrics is only to track those that apply to the team. Ignore those metrics that measure the individual.
The second rule of tracking metrics is not to measure parameters just because they are easy to follow. This practice often is a consequence of using various agile tools that offer out-of-the-box reports.
The third rule of tracking metrics is to record context as well. For example, data without context, the number of available team members, or the intensity of incidents during a sprint may turn out to be nothing more than noise.
Examples of suitable agile metrics are:

Lead time,
Cycle time,
Number of defects escaping to production, or
Ratio of fixing work to creating new value.
Good candidates should be aware of the evidence-based management concept.

Measuring the health of a Scrum Team — that is, getting an idea about current levels of engagement and satisfaction — is useful for identifying trends that may affect productivity and team cohesion.

For example, one effective method of measuring the health of a Scrum Team is to circulate an anonymous multiple-choice questionnaire before the team’s Sprint Retrospectives. A questionnaire that requires just two minutes to complete and uses a simple scale for each of the questions — from 1 (terrible) through 2 (poor), 3 (neutral), 4 (good), to 5 (excellent) — is usually well-suited.

During the Sprint Retrospective, the team should discuss the results with an aim to uncover any concerns or frustrations they may be harboring. (See above, gathering data.)

Typical Scrum Sprint Retrospective anti-patterns are:

Waste of time: The team does not collectively value the Sprint Retrospective. If some team members consider the Sprint Retrospective to be of little or no value, it is most often the Sprint Retrospective itself that sucks. Is it the same procedure every time, ritualized and boring? Have a meta-Sprint Retrospective on the Sprint Retrospective itself. Change the venue. Have a beer- or wine-driven Sprint Retrospective. There are so many things a Scrum Master can do to make Sprint Retrospectives interesting and valuable again, reducing the absence rate. Furthermore, it is good to remember that (in my experience) introverts like to take part in Sprint Retrospectives also.
Prisoners: Some team members only participate because they are forced to team up. Don’t pressure anyone to take part in a Sprint Retrospective. Instead, make it worth their time. The drive to continuously improve as a team needs to be fueled by intrinsic motivation, neither by fear nor by order. Tip: Retromat’s “Why are you here?” exercise is a good opener for a Sprint Retrospective from time to time.
Groundhog day: The Sprint Retrospective never changes in composition, venue, or length. In this case, the is that the team will revisit the same issues over and over again – it’s like Groundhog Day without the happy ending.
Let’s have it next Sprint: The team postpones the Sprint Retrospective into the next Sprint. Beyond the “inspect & adapt” task, the Sprint Retrospective serves as a moment of closure, helping reset everybody’s mind so that the team can focus on the new Sprint goal. That is the reason why we have the Sprint Retrospective before the planning of the follow-up Sprint. Postponing it into the next Sprint may also interrupt the flow of the team, and delay tackling possible improvements by up to a Sprint. This is why it is important to have the Sprint Retrospective before the planning of the follow-up Sprint.
#NoDocumentation: No one is taking minutes for later use. A Sprint Retrospective is a substantial investment for many reasons and should be taken seriously. Taking notes and photos supports the process.
No psychological safety: The Sprint Retrospective is an endless cycle of blame and finger-pointing. The team wins together, the team loses together. Unfortunately, the blame game documents both the failure of the Scrum Master as the facilitator of the Sprint Retrospective as well as the team’s lack of maturity and communication skills.
Bullying: One or two team members are dominating the Sprint Retrospective. This communication behavior is often a sign of either a weak or uninterested Scrum Master. The Sprint Retrospective needs to be a safe place where everyone–introverts included–can address issues and provide their feedback free from team members who are dominating the conversation, bullying or intimidating other teammates. The failure to provide a safe place will result in participants dropping out of the Sprint Retrospective and render the results obsolete. It is the main responsibility of the Scrum Master to ensure that everyone can be heard and has an opportunity to voice their thoughts. According to Google, equally distributed speaking time fosters and signifies a high-performing team. Read More: “What Google Learned From Its Quest to Build the Perfect Team.”
Stakeholder alert: Stakeholders participate in the Sprint Retrospective. There are plenty of Scrum events that address the communication needs of stakeholders: the Sprint Review, the Product Backlog refinement, the Daily Scrum events – not to mention opportunities of having a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is still not sufficient, feel free to have additional meetings. However, the Sprint Retrospective is off-limits to stakeholders.
Passivity: The team members are present but are not participating. There are plenty of reasons for such a behavior: they regard the Sprint Retrospective as a waste of time, it is an unsafe place, or the participants are bored to death by its predictiveness. The team members may also fear negative repercussions should they be absent, or maybe a homogenous group of introverts was unwittingly hired. Whatever the reason, there is likely no quick fix. The Scrum Master needs to determine what style of Sprint Retrospective will work best in their organization’s context.

The Agile Manifesto infers people over processes. Isn’t a Scrum Master — whose role is meant to “enforce” the process — therefore a contradiction?

Scrum Masters do not wield any real authority but act as servant leaders. The Scrum Team does not report to them. This question is meant to help reveal whether your candidate understands that their role is to lead — as opposed to manage — the team. Asking this question is also likely to reveal why your candidate is interested in the role of a Scrum Master in the first place.

Acceptable answers should emphasize facilitation and support, for example:

“I am the servant-leader for the Scrum Team. It’s my job to make them successful.”
“I am neither a project manager nor a people manager. I support the Scrum Team in achieving self-organization. I do not tell people what to do.”
“I am the Scrum Team’s facilitator as teacher, coach, or mentor, encouraging them to excel as a team.”

A Product Owner should not take this shortcut and turn requirements documents received from stakeholders into work items, and a Scrum Master should never accept such a procedure. It’s nothing more than a waterfall process dressed-up as a pseudo-agile practice.

If an organization is supposed to focus on delivering value to its customers, it is essential that any process involving ’requirements’ being handed down to its engineers by a project manager be abandoned. It makes no difference if the project manager is posing as a Product Owner. Instead, the organization should start including everyone in the product discovery process, thereby ensuring a shared vision of what needs to be built.

A Product Owner individually assigning user stories to members of a Development Team is not Scrum, and if a Product Owner is doing this they need to be stopped. Development Teams are self-organizing. The assignment of user stories and the distribution of tasks among the members of a Development Team is the prerogative of the team itself. Preventing this anti-pattern should be one of the Scrum Master’s most pressing concerns.

There are no leadership roles in the Development Team. However, it’s not uncommon for some members of a Development Team to assume leadership. This typically happens when a particular team member possesses superior (technical) expertise, communication skills, or simply a greater level of engagement.

All teams go through Tuckman’s stages of team development: forming, norming, storming, and performing. Scrum Teams are no exception.

It’s important that when a member of a Development Team assumes leadership this does not result in other members reporting to them. A Scrum Master must be vigilant and intervene if necessary to ensure that all team members communicate and work together — during Daily Scrums and otherwise — in the spirit of Scrum.

A Sprint is heart of Scrum. Sprint is a time boxed container which has all 4 mandatory events Sprint Planning, Daily Scrum, Sprint Review & Retrospective. It’s a repeatable event of maximum 1 month or less during which Team delivers a potentially releasable software or solution.During the Sprint:

No changes are made that would endanger the Sprint Goal
Quality goals do not decrease
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Any Product Backlog larger than the scope of two or three Sprints is barely manageable. Misusing a Product Backlog by adding hundreds of items to it is a clear sign that the Product Owner needs help from the Scrum Team or the Scrum Master to better cope with an influx of ideas, suggestions, and requirements. A smaller Product Backlog avoids misallocating resources; a larger Product Backlog is an indication of waste.

Your candidate should make it clear that they would support a Product Owner in dealing with the size of the Product Backlog, and the ideation process in general, for example, processing input from stakeholders and customers.

This question revisits the previous. Again, your candidate should focus on explaining why involving the Scrum Team early in the product discovery process is beneficial for both the Product Owner and the organization.

Additionally, Scrum Masters can effectively support Product Owners by ensuring that the Product Backlog refinement process is continuous and of a high value regarding the Product Backlog. “Garbage in, garbage out“ does apply to Scrum. Essentially, the Scrum Team either wins together or loses together.

The catch: This is a tricky situation – if you say that you will accept defects midway you are playing with change of sprint goal mid of the sprint which is a No-No and if you say you won’t accept defects midway then you are not solving the business problem.

Answer: There are multiple options
a) Scenario 1: I can have 2 different teams – 1 for Feature Development and other for defect fixing. (Ideal)
b) Scenario 2: Based on the trend of defects, I can limit my planned features and leave the scope for defects handling. This way you are not playing with Sprint Goal
c) Scenario 3: Reduce the sprint length if the defects SLA is not too short like something below a week to accommodate incoming defects in next sprint.
How to:
• You can go through a Scrum Master Certification or Kanban KMP1 Certification and KMP2 Certification will give you in depth knowledge. Read more about Scrum master interview questions.

There is no standard or general definition of ‘agile success’ that can be used to measure an organization’s agility. Every organization must develop its own criteria. Increasing team velocity is usually not considered to be a meaningful indicator.

However, although mostly indirect, there are various indicators that may be useful in determining success:

Products delivered to customers are resulting in higher retention rates, better conversion rates, increased customer lifetime value, and similar improvements to the business. (A successful Scrum Team provides a good return on investment to the business.)
The improved organizational agility allows pursuing market opportunities successfully, which previously would have been considered futile.
There has been a reduced allocation of resources to low-value products.
Lead time, from validated idea to shipped product, has been reduced.
The cycle time for hypotheses validations has been reduced, speeding up the product discovery process.
Improved team happiness is exhibited by reduced churn and an increase in the number of referrals from team members.
Increased competitiveness in the war for talent can be demonstrated by an increase in the number of experienced people willing to join the organization.
Increased software quality can be demonstrated by measurably less technical debt, fewer bugs, and less time spent on maintenance.
There is greater respect among stakeholders for the product delivery teams.
Stakeholders are increasingly participating in events, for example, during the Sprint Review.

Information that a Scrum Master might require from a Product Owner when wanting to update their team on the product, or a market’s reaction to it, would include any information that could provide the Scrum Team with an understanding of why something is of value to customers. Such information may be of a quantitative nature (e.g. analytical data describing how a process is utilized) or of a qualitative nature (e.g. transcripts, screencasts, or videos from a user testing session).

An excellent suggestion on the part of your candidate would be for the Scrum Team to participate in gathering qualitative signals by taking part in user interviews.

Please note: Normally, the Product Owner would provide this information during Sprint Reviews or the refinement process. Noting that the question Q12 itself is pointing at an anti-pattern, that would make a good topic for a Retrospective, is a bonus for the candidate.

A Development Team has autonomy in how its members choose to distribute tasks, so it may be that a presumed cherry-picking of tasks by individual team members is in fact a valuable and crucial part of the team’s path to performance.

However, if team members are complaining about how others are choosing their tasks, the Scrum Master needs to address the issue. Additional training might help some team members accommodate a greater variety of tasks. Or, perhaps, other team members may need to be gently pushed out of their comfort zone so that they will more readily choose different kinds of tasks over what they’ve become accustomed to. Pair programming may be a suitable first step in that direction.

An anti-pattern of this behavior is when specific tasks, such as quality assurance, are regularly left to the same team members. This pattern reintroduces sub-roles to the Development Team — and needs to be addressed by the Scrum Master.

Refer to Question 25, where addressing this similar attitude and the behavioral problem is discussed at length. Your candidate’s answers should address similar points.

There are various Sprint Retrospective formats in common use, and each is meant to accommodate different situations. Your candidate should have experience applying more than one of these formats and should be able to share their logic for having done so. Some basic formats for Retrospectives include:

The classic format:
What did we do well?
What should we have done better?
The boat format:
What’s pushing us forward?
What’s holding us back?
The starfish Sprint Retrospective:
Start doing…
Do less of…
Do more of…
Stop doing…
Continue doing…
You can embed all of these formats in the general Sprint Retrospective format popularized by Diana Larsen and Esther Derby:

Set the stage.
Gather data.
Generate insights.
Decide what to do.
Close the Sprint Retrospective.
There are several websites available that help Scrum Masters to customize Retrospectives to the needs of the Scrum Team, such as Retromat or Tasty Cupcakes. Alternatively, Liberating Structures provide excellent tools, too.

Suitable candidates will elaborate passionately about their preferred ways and tools for delivering Retrospectives. Candidates that provide only mechanical answers require more scrutiny as the Sprint Retrospective is a key event from a Scrum Master’s perspective.

The purpose of qualitative metrics is to gain insight into how one or more of an organization’s Scrum Teams are progressing with agile.

There are several self-assessment tests available that a Scrum Team can regularly run to collect qualitative metrics about their implementation of Scrum — Hendrik Kniberg’s Scrum Checklist is a good example. The interval to test via self-assessment is every 4–12 weeks, with teams of lesser fluency running their tests at the lower end of this range. The individual values recorded by these tests are not very important, but the trend over time is. To visualize these trends, a Scrum Master will need to aggregate the results — in the case of Henrik Kniberg’s checklist, an agile practice map may be created over time.

While self-assessment tests like Henrik Kniberg’s checklist are usually team exercises for recording implementation metrics, sentiment metrics are best captured by running anonymous opinion polls to ensure the participation of the more introverted team members.

Using opinion polls, typical questions for recording sentiment metrics include:

What value did the team deliver in the last Sprint?
Has the level of technical debt increased or decreased during the last Sprint?
Are you happy working with your teammates?
Would you recommend your employer (or client) to a friend seeking a new job?
It’s best to run opinion polls after every Sprint; these polls should only require a few seconds to complete. As with the self-assessment tests, the individual values recorded by running anonymous opinion polls are not very important — it’s the trend over time that matters. Trends derived from these polls are great points for discussion during a team’s Sprint Retrospectives.

Concerning metrics in general, your candidate should support the Agile Manifesto and its principle of transparency: all metrics should be available to all members of a Scrum Team, and largely also to those working in the product delivery organization generally.

This is a simple question: Regularly ask your team and stakeholders how you can improve as a Scrum Master.

Why not run a Sprint Retrospective on yourself? A dedicated Sprint Retrospective is much more effective than spending five minutes, asking for hints at how you might improve, at the end of each regular team Sprint Retrospective.

Good candidates also note that they proactively provide user manuals on how to work with themselves to other team members and the organization.

A Scrum framework has three roles:

Scrum Master
Product Owner
Development Team
There are no other roles than these but beyond Product organization, they can have other organizational roles too. Scrum does not speak anything on these roles and this depends on organization to organization.

Definition of Done is the checklist of activities that need to be completed in order to call the Product Backlog Item (requirements) DONE so that it can be part of potentially releasable increment. This is common understanding between the PO and Dev Team. This is generally formulated at the start of the first sprint and which can be enhanced later on as the understanding of the Scrum team enhances.

Waterfall method and the Scrum method can be used hand in hand to get the maximum desired output with the collaborative approach. But at times, there is a need when you need to go with the waterfall method despite of the Scrum method or their collaborative approach.

The waterfall method is the simplest approach to the software development process while Scrum is specially designed to have long term effect with complex integration of its principle. So here are some of the places where one needs to prefer waterfall method over scrum method.

When the project is simple:

The waterfall method is the best possible process to use for simple project development and implementation. Unlike big projects which need teams building with a cross-functional collaborative approach and appropriate use of Agile Methodology, Waterfall method should be preferred to have a simple approach for the small projects.

When the project is complicated:

Waterfall method can be preferred for complicated projects. But the thing which makes appropriate use of the Waterfall method with complicated projects are expertise hands. Expertise hands are best to analyse the complications of a project and with approach of the waterfall model, they can design a simple and subtle approach to develop the projects.

To focus on delivery date and budget:

If with the development of software budget there comes a deadline then the waterfall method should be preferred over any other. The deadlines can be the delivery date of product or with the budget of software development or on the focused approach of performance the developed software.

When Investment is not risky:

The software development cycle is a long process and the risk of investment needs to get configured accordingly with the need. But with the software development method where investment is not risky and they have a path for the simplest approach, the Waterfall method needs to be preferred at first for the development process.

The Agile Manifesto infers people over processes. Isn’t a Scrum Master — whose role is meant to “enforce” the process — therefore a contradiction?

Scrum Masters do not wield any real authority but act as servant leaders. The Scrum Team does not report to them. This question is meant to help reveal whether your candidate understands that their role is to lead — as opposed to managing — the team. Asking this question is also likely to reveal why your candidate is interested in the role of a Scrum Master in the first place.

Acceptable answers should emphasize facilitation and support, for example:

“I am the servant-leader for the Scrum Team. It’s my job to make them successful.”
“I am neither a project manager nor a people manager. I support the Scrum Team in achieving self-organization. I do not tell people what to do.”
“I am the Scrum Team’s facilitator as teacher, coach, or mentor, encouraging them to excel as a team.”

When answering this question, your candidate should explain that there is no simple way to ensure access to stakeholders.

For example, in larger organizations, functional silos, budgeting and governance practices, and the organizational hierarchies often effectively limit team members’ access to stakeholders. Overcoming this organizational debt, thus building trust among all participants, is a prime objective for the work of Scrum Masters.

Your candidate might suggest encouraging stakeholders to engage in effective (transparent, helpful) communication. Sprint Reviews are a useful venue for this, and the interaction often promotes better relationships between different departments and business units.

Velocity is the average size of DONE requirements (Stories or any form of requirement) successfully delivered by the team every sprint in the past. Generally, it is calculated by averaging all the story points from the previous Sprints. It works as a guideline for the team to understand the number of stories they can do in a Sprint on an average.

Scrum Masters play a veritable role in development and deployment of Software Projects. The need for Scrum Master is soaring high in the market with the evolution of Scrum Framework into much use.

The prerequisites and responsibilities of a Scrum Master are very broad. From managing the team and leading them to being an interface between the product owner and development team, the roles of Scrum Master needs to be configured and analysed very carefully.

To get yourself recognized as a good and expert Scrum Master one needs to get trained at first. Scrum Framework is a lightweight model but to master the model always remains a tough task to do. And so for the same one needs to get trained under an expert hand who delivers the exact concepts of Scrum Framework into use for the working process.

The trainers take you through every insight of how to deploy the principles of Scrum Framework into use. This includes covering all the activities and information needed for the role of Scrum Master with the depth knowledge of every section and stages. And so for the same getting yourself certified is a must need.

The certification of Scrum Master gives a detailed view of the structure and working of the Scrum Framework. It helps the Scrum Master to manage the team accordingly and deliver results of high-quality value.

Learning every single step under Scrum Certification course helps the Scrum Master to react to the blockages and backlogs very quickly and get this things resolved at an efficient pace.

With the growth and success of Scrum Framework into the working environment of Software industry with time, outlook and reach for Scrum Master has grown exponentially with time and demand for Scrum Masters are soaring high with the time.

There is no standard or general definition of ‘agile success’ that can be used to measure an organization’s agility. Every organization must develop its own criteria. Increasing team velocity is usually not considered to be a meaningful indicator.

However, although mostly indirect, there are various indicators that may be useful in determining success:

Products delivered to customers are resulting in higher retention rates, better conversion rates, increased customer lifetime value, and similar improvements to the business. (A successful Scrum Team provides a good return on investment to the business.)
The improved organizational agility allows pursuing market opportunities successfully, which previously would have been considered futile.
There has been a reduced allocation of resources to low-value products.
Lead time, from validated idea to shipped product, has been reduced.
The cycle time for hypotheses validations has been reduced, speeding up the product discovery process.
Improved team happiness is exhibited by reduced churn and an increase in the number of referrals from team members.
Increased competitiveness in the war for talent can be demonstrated by an increase in the number of experienced people willing to join the organization.
Increased software quality can be demonstrated by measurably less technical debt, fewer bugs, and less time spent on maintenance.
There is greater respect among stakeholders for the product delivery teams.
Stakeholders are increasingly participating in events, for example, during the Sprint Review.

There are various tactics a Scrum Master can use to engage stakeholders with Scrum, for example:

Most importantly, a Scrum Master should live and breathe the principles of the Scrum Guide and the Agile Manifesto. They should talk to everyone in the organization involved in building the product, and they should be transparent about what they do. (Read more: 10 Proven Stakeholder Communication Tactics During an Agile Transition.)
Product and engineering teams can produce evidence proving to stakeholders that Scrum is significantly reducing the lead time from idea to product launch.
Product and engineering teams can demonstrate that Scrum mitigates risk (i.e. the forecast of when new features could be made available), thus contributing to other departments’ successes in planning and execution.
A Scrum Team can be transparent with respect to their work and proactively engage stakeholders by inviting them to Sprint Reviews and other events where the team communicates their activity or progress.
Training for everyone in the organization, particularly the stakeholders, is important. One hands-on approach is to organize workshops designed to teach agile techniques for non-technical colleagues.

Ideally, Scrum does not suggest or justify usage of tools but there are quite a few tools which helps Iterative implementation and those are

Simple Excel (Customized as per need)
Atlassian JIRA.
Version One.
RTC Jazz
Sprintster

Daily Scrum is 15 minute sync up for the team which happens the same time – the same location every day. It helps the team self-organize towards their sprint goal and set the context for the day’s work. It is an inspect and adapt meeting where they inspect if the progress towards sprint goal is good and adapt if any changes required. This sync up event sets the tone for the day and reduced the need for any more meetings throughout the day.

Scrum Master makes sure this event happens and helps the team understand how to do a Daily Scrum effectively.

If you don’t know where you are going, any road will get you there. Your candidate should understand that an agile transition needs to have an objective and a goal — which means planning ahead.

To prepare for kicking off a transition to Scrum is to listen and observe: your candidate should express interest in interviewing as many team members and stakeholders as possible, before jumping into action. These interviews should include everyone, no matter their role — engineers, QA professionals31, UX and UI designers, product managers — in order to identify the patterns underlying current problems, failures, and dysfunction within the organization. Merging those patterns with the most pressing technical and business issues will identify the most likely objectives for the first Scrum Teams. This observation phase, during which a Scrum Master performs their interviews, will typically require between four and twelve weeks depending upon the size and structure of the organization.

The training of future team members and stakeholders should commence and run parallel to the interviews.

Creating the first Scrum Teams from the existing engineering and product departments is the second step in kicking off a transition to Scrum.

Your candidate should be able to sketch the rough plan of a transition and address common issues that might arise during kickoff.

Writing user stories should be a joint effort by all members of a Scrum Team—card, conversation, confirmation. If it’s not, the team might not feel that they have ownership of the work items — inevitably leading to less or no commitment, reduced motivation, and ultimately a lower-quality product. Additionally, handing down user stories reduces the accuracy of forecasts by the Development Team members as the joint creation process creates the shared understanding necessary.

It is the prerogative of the Product Owner to define the business objective of an upcoming Sprint by identifying and ranking the most valuable user stories in the Product Backlog, and it is the duty of the Scrum Master to support the Product Owner in this. Pursuant, a suitable way for a Scrum Master to support a Scrum Team’s strive to work on the most valuable Product Backlog items is:

To ensure that the Scrum Team is involved in the product discovery process at an early stage;
To ensure that the Product Backlog refinement process is well practiced by both the Development Team members and the Product Owner; and
To ensure that all user stories are created in a collaborative effort between the Product Owner and the Development Team members (the goal being a shared understanding of the user stories and thus joint ownership).
Your candidate should note that although the Product Owner practically outlines the scope of the Sprint, it is the prerogative of the Development Team to address technical debt and bugs during the same Sprint. A Development Team should be able to allocate up to 25% of their available capacity for this.

Whether an incomplete user story should be added to the Sprint Backlog depends upon the Development Team’s present concerns and experience with the circumstances. In the case of an incomplete or missing user interface (UI) design, for example, if the design team is almost certain to deliver because they have done so in the past, and if the user story is high value, and if the story can be accomplished within the Sprint despite its UI deliverables arriving late, and if the Development Team agrees to it — then an exception may be acceptable.

Beware that exceptions have a tendency to become accepted practices. An organization’s intent on being agile should not be allowed to bypass the Product Backlog refinement and Sprint Planning process. Your candidate should be aware that such situations are not tenable. Furthermore, if the implementation of a work item subjected to such an exception fails, no one will bother to read the fine print and acknowledge that an exception had been made. Instead, they will most likely view the Scrum process itself as having failed.

Your candidates may either accept or reject exceptions to the process. But they should also be able to analyze situations in which exceptions have been made, and explain the collateral damage that the Scrum Team may be exposed to.

Asking this question can easily spark a philosophical discussion about whether stakeholders should be allowed to participate in a Development Team’s Daily Scrums. Try to avoid this.

If stakeholders participate in a Development Team’s Daily Scrums, is it likely to result in a form of reporting that circumvents Scrum rules? Not necessarily. It’s good if some adaptation of Scrum can be made to work for an organization. Allowing stakeholders to participate in Daily Scrums need not be ruled out if the Development Team finds it acceptable. In fact, if stakeholders attend Daily Scrums regularly, this invariably and significantly improves communication between a team and their stakeholders.

So shall a Scrum Master encourage stakeholders to attend Daily Scrums? That depends on the context; your candidate should not rule out their participation immediately.

A Scrum Master should not be concerned with removing problems that the Scrum Team can solve themselves, no matter how often this requirement is mentioned in job advertisements. If a Scrum Master acts like a ‘Scrum helicopter parent,’ their team will never become self-organizing.

A Scrum Team must learn to make its own decisions. This almost inevitably results in failures, dead-ends, and other unplanned excursions when the team is learning something new. Consequently, in the beginning, a team will need more guidance than usual from the Scrum Master — and of a different kind than exemplified by drawing offline boards (see Questions 31 and 32) or updating tickets in JIRA. Such guidance should not, however, become an exercise in protective parenting — a team must be allowed to learn from their failures.

That being said, there is one area where the Scrum Master is indeed removing problems on behalf of the team. This applies when the Scrum Team cannot solve the problem by themselves, for example, because the issue is an organizational problem. Now we are talking about “impediments.” Only in this situation, the Scrum Master becomes the impediment remover of the Scrum Team.

When required to attend an uninspiring Sprint Retrospective, members of a Scrum Team will become bored.

There are many possibilities for variation that can be used to prevent a Sprint Retrospective from being boring, and team members from becoming bored. A different location, a different format, and shortening or lengthening the allotted time box are just some of the variations that can be tried.

Scrum Masters might also use a team’s choice of action items to encourage and structure discussions around issues that matter to the team, thus creating engagement through acknowledgment. Web sites like Retromat offer hundreds of different games and exercises to make Sprint Retrospectives enjoyable and valuable for the whole team.

There is no single solution, and consequently no single correct answer, to either boredom or this question. What’s important is that your candidate acknowledges that boredom with routine might become an issue and that there are ways to deal with it.

The Scrum Master:

Is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
Acts as a servant-leader for the Scrum Team.
Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.
It helps everyone change these interactions to maximize the value created by the Scrum Team.
In simple words, SM is a person who believes in Scrum Values and processes and motivates everyone to follow it and creates an environment for everyone to follow it.

The Product Owner focuses on the success of the product, ensuring the business value of it. Their main responsibility is to identify and refine the Product Backlog items. Product Owner is the voice of customer for Team and represents customer often. PO keeps product Backlog up to date and guides team on when to deliver what part of Product Backlog.

A servant leader
Who puts teams needs ahead of his/her
Who fosters leadership in team
A good impediment resolver
Patient listener
Coach to individuals and team
A protector for team
An effective facilitator

Scrum Framework is itself an approach of Agile Methodology for product development. Agile is a long term process and Scrum is a slow term process. So going with the Scrum makes work more process more efficient by breaking the system into sprints. These Sprints help in delivering quality product in a short time period and adds the value for the subtle approach with Agile Methodology. Their collaborative approach not only gives quality product but also helps to remove blockages very easily with high efficiency.

Agile and scrum are two different approaches and so here are some differences between features of both of them:

Agile development is based on the iterative and incremental approach and with Scrum Framework it is implemented a way with which incremental builds are delivered to customer every 2-3 weeks.

Agile gives a leader and Scrum is mostly dependent on self-organised cross-team functioning. Eventually when both have a collaborative approach to product development high-quality product is delivered.
Agile is rigid method while Scrum Framework is rather a flexible approach.
Agile asks for a simple design and execution of software product but Scrum fosters innovative and incremental approach.
The most elementary measure of progress in the Agile Method is working software but with Scrum, working software is not a priority.
Customer competitive advantage through everyday work approach, technical advancements and adjusting the behavior is the principle of Agile Methodology which when structured with Scrum Framework gives a more incremental approach to a self-organised cross functional team with the efficient performance for collaborative iterative development approach.

A Scrum Master should not be concerned with removing problems that the Scrum Team can solve themselves, no matter how often this requirement is mentioned in job advertisements. If a Scrum Master acts like a ‘Scrum helicopter parent,’ their team will never become self-organizing.

A Scrum Team must learn to make its own decisions. This almost inevitably results in failures, dead-ends, and other unplanned excursions when the team is learning something new. Consequently, in the beginning, a team will need more guidance than usual from the Scrum Master — and of a different kind than exemplified by drawing offline boards (see Questions 31 and 32) or updating tickets in JIRA. Such guidance should not, however, become an exercise in protective parenting — a team must be allowed to learn from their failures.

That being said, there is one area where the Scrum Master is indeed removing problems on behalf of the team. This applies when the Scrum Team cannot solve the problem by themselves, for example, because the issue is an organizational problem. Now we are talking about “impediments.” Only in this situation, the Scrum Master becomes the impediment remover of the Scrum Team.

This is a deliberately open question meant to encourage discussion. In answering this question, your candidate should elaborate on how they would spread an agile mindset throughout an organization or, ideally, and more specifically, how they would create a learning organization that embraces experimentation in order to identify the best product for its customers.

A good candidate is likely to talk about the necessity of ‘selling’ agile to the organization in order to win the hearts and minds of the stakeholders. They will also point at the necessity to find a high-ranking executive to sponsor the transformation.

At the beginning of a transition any organization shows inertia to change, so to overcome this resistance executives and stakeholders need to know how Scrum will benefit them before they’re likely to make a commitment. (Read more: The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders.)

One practical approach when introducing Scrum to senior executives is to organize workshops for higher management levels. Applying Scrum at the executive level has been successful in the past. Executives, and potentially even key directors, can gain a first-hand experience with agile practices if organized as a Scrum Team.

There is no right or wrong answers to this question. Good practices need to take into consideration an organization’s culture, size, product maturity, legal and compliance requirements, and the industry it is operating in.

There are quantitative as well as qualitative measurements that may be used to assess the value of a user story or whether the investment is worthwhile. These may include, for example:

Revenue increases,
Cost-cutting benefits achieved by internal process improvements,
Increases in customer satisfaction rates (NPS),
Increases in signups for new products, or
Positive customer feedback received by the customer care team.

When an organization is transitioning to Scrum and at the same time dealing with significant organizational, business, and technical problems, the founding members of its Scrum Teams should be volunteers who fully understand the challenge ahead of them, rather than people pressed into service. The best volunteers are those eager to prove that becoming agile is the most effective way to reach an objective.

Candidates for the role of Scrum Master should be astute enough to suggest inviting every member of the product delivery team, as well as the C-level executives sponsoring the transition, to a kickoff meeting. The objective of a transition kickoff meeting is to support the members of the engineering and product teams in how they choose to self-organize into the first cross-functional Scrum Teams. Transition kickoff meetings can last a few hours or several days, depending upon the circumstances of a particular organization.

Despite the importance of the kickoff meeting to a Scrum transition, going much deeper into its structure will take too much time from the interview. It’s more important that your candidates embrace the idea of team self-selection and present a brief roadmap of what should happen next for the newly formed Scrum Teams.

Although somewhat dependent upon the existing skills, experience, and training of the members of an organization’s new Scrum Teams, your candidates should anticipate having to teach the very basics of Scrum following a kickoff meeting. They might propose doing this through a series of workshops or on-the-job training with exercises in Product Backlog refinement, writing user stories, estimating, creating boards, and setting up collaboration software.

There are multiple tools like Burn up, burn down but most famous is Burn down charts. Here we check daily the amount of work remaining compared to the planned. Here in below burn down chart the Orange line is ideal burn down rate per day required to finish things on time and gray like is the actual remaining to finish things recorded every day, especially during the Daily Scrums.

Any incomplete work getting postponed to the next sprint is called scope creep if it happens regularly. The work gets postponed to the upcoming sprints and we never catch up. This can be due to many factors like

Unclear requirements accepted in Sprint
Skills not available
Definition of Done is not clear
No intermediate and immediate Demo to PO and last minute changes suggested
Acceptance criteria keep changing
Silos in requirement implementation in place of combined ownership
Improper or no Backlog refinement
To prevent it:

A proper and effective retrospective to understand the root causes and eradicate the top reasons for creep
The requirements must be clearly specified with acceptance criteria
Daily progress monitoring by team during Daily Scrum.
Effective backlog refinement of sprint backlog must be done.
Combined ownership of features/stories so that we focus on work completion than individual ownership and silos

If the member of a Development Team does not want to participate in Sprint Planning and considers the meetings a waste of time, they’re exhibiting a type of passive-aggressive behavior. Although not particular to Scrum, this is a problem because the underlying attitude is toxic and will affect both team-building and team performance as now the knowledge of a team member will not be available at Sprint Planning.

When the member of a Development Team behaves as described, the team’s Scrum Master needs to take action. Counterproductive behavior can neither be ignored nor tolerated if the team is to continue functioning. Effective action is likely to require probably a series of escalating steps:

The Scrum Master may start by addressing the team member privately to discuss their reservations and, perhaps, more coaching needs or a longer training period.
Following private discussion, the entire Scrum Team can be involved by making the team member’s reservations a topic of discussion during one or more Sprint Retrospectives. This enables the Scrum Team to offer their support to their teammate.
If there is still no change in the team member’s attitude, a meeting with the team member and their line-manager is advisable.
If no change can be achieved, it might be possible to reassign the team member to another (probably non-agile) team, or to a Kanban team unlikely to force the team member out of their comfort zone.
Situations such as described highlight how Scrum is not meant for everybody.

Daily Scrums for Development Teams whose members are distributed between different offices or working remotely are not much different from Daily Scrums for Development Teams whose members are co-located. The exception is that distributed teams sharing board activity may require video conferencing when working with offline boards that mirror each other.

If a Scrum Team is using online task management or planning software like JIRA, the team’s boards can be online and updates can take place on-screen. This generally makes it easy for members of a distributed team to follow board activity. With online boards in place, a Zoom or Google Hangouts call will likely be enough for a distributed team to have their Daily Scrum.

Alternatively, the Development Team may try an asynchronous Daily Scrum by utilizing messenger software like Slack. It is the prerogative of the Development Team to decide on the best way of handling their Daily Scrum event.

During a Sprint Retrospective, the members of a Scrum Team would usually pick some action items — tasks to be done — and include them in the upcoming Sprint Backlog. If these action items are subsequently not completed in a timely manner, the Scrum Master needs to follow up.

A team might not be completing the action items they’ve picked because they’ve run into an external impediment. If this is the case, the Scrum Master has to address the cause, and the team can then catch up during a later Sprint.

However, if there is no external impediment, the problem is likely due to motivation, attitude, or personal issues within the Scrum Team. In this latter case, the Scrum Master needs to provide the team members with sufficient encouragement or motivation to overcome the problem — a Scrum Team is self-organizing.

If a team is not completing the action items they’ve picked and the problem ultimately cannot be resolved, picking action items becomes a useless exercise and the Scrum Team’s continuous improvement effort will suffer as a result.

A good user story:

Includes a description,
Has acceptance criteria defined,
Can be delivered within a single Sprint,
Has all UI deliverables available,
Has all (probable) dependencies identified,
Has performance criteria defined,
Has tracking criteria defined, and
Is estimated by the Scrum Team.

There are various tactics a Scrum Master can use to engage stakeholders with Scrum, for example:

Most importantly, a Scrum Master should live and breathe the principles of the Scrum Guide and the Agile Manifesto. They should talk to everyone in the organization involved in building the product, and they should be transparent about what they do. (Read more: 10 Proven Stakeholder Communication Tactics During an Agile Transition.)
Product and engineering teams can produce evidence proving to stakeholders that Scrum is significantly reducing the lead time from idea to product launch.
Product and engineering teams can demonstrate that Scrum mitigates risk (i.e. the forecast of when new features could be made available), thus contributing to other departments’ successes in planning and execution.
A Scrum Team can be transparent with respect to their work and proactively engage stakeholders by inviting them to Sprint Reviews and other events where the team communicates their activity or progress.
Training for everyone in the organization, particularly the stakeholders, is important. One hands-on approach is to organize workshops designed to teach agile techniques for non-technical colleagues.

By helping in Scrum adoption in the organization.
Acting as a catalyst and change agent for Scrum adoption in Org.
Catalyzing changes that can help the team, be more productive sprint by sprint.
Fostering culture of continuous improvement sprint by sprint in team and organization.
Supporting Agile leadership principles, leading to organizational transformation.
Helping other Scrum Masters to increase the effectiveness of Scrum implementation in their teams and organization.

Product Owner is served by Scrum master in the following ways:

Make sure goals, scope & product domain are understood by everyone on the Scrum Team as well as possible;
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
Finding techniques for effective Product Backlog management; eg – different Prioritization techniques like MoSCoW & Requirement breaking and Business value allocation techniques
Helping know how to do product planning in an empirical situation;
Making sure that Product Owner knows the ways to arrange the Product Backlog to maximize product & business value
Understanding and practicing agility &
Facilitating Scrum events as requested or needed. (Makes sure events happen and inappropriate way & help course correction & coach if required)

This is a deliberately open question meant to encourage discussion. In answering this question, your candidate should elaborate on how they would spread an agile mindset throughout an organization or, ideally, and more specifically, how they would create a learning organization that embraces experimentation in order to identify the best product for its customers.

A good candidate is likely to talk about the necessity of ‘selling’ agile to the organization in order to win the hearts and minds of the stakeholders. They will also point at the necessity to find a high-ranking executive to sponsor the transformation.

At the beginning of a transition any organization shows inertia to change, so to overcome this resistance executives and stakeholders need to know how Scrum will benefit them before they’re likely to make a commitment. (Read more: The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders.)

One practical approach when introducing Scrum to senior executives is to organize workshops for higher management levels. Applying Scrum at the executive level has been successful in the past. Executives, and potentially even key directors, can gain first-hand experience with agile practices if organized as a Scrum Team.

There is no right or wrong answer to this question. Good practices need to take into consideration an organization’s culture, size, product maturity, legal and compliance requirements, and the industry it is operating in.

If a Development Team is involved early enough in either user story selection (preferably by jointly creating the stories with the Product Owner) or product discovery, a Scrum Master will probably not need to provide any guidance to see that the most valuable stories are chosen.

If a Development Team resorts to cherry-picking — choosing user stories only to satisfy personal preferences — during Sprint Planning, the Product Backlog refinement process needs to be seriously inspected. In all likelihood, the Product Owner is probably focusing on Product Backlog items that are not maximizing customer value.

In answering this question, your candidate should exhibit common sense regarding “ritualized” Daily Scrums. Daily Scrums are an important part of Scrum, but not all Daily Scrums need to be formal — a Development Team should not have a Daily Scrum for the sake of having it; it serves a different purpose than ticking off a box on a checklist. A small, experienced, and co-located team may use a morning coffee break for their Daily Scrum.

Nevertheless, the Daily Scrum is the essential inspect & adapt event of the Development Team: are we still on track accomplishing the Sprint Goal? Or have we learned something since the previous Daily Scrum that requires to change our plan of how to achieve the Sprint Goal?

In this question, the qualifier ‘Kanban’ is used as a teaser. Anyone interviewing for the role of Scrum Master should be able to draw a simple Sprint board.

The columns of a Sprint board should usually include columns such as:

Backlog of tasks,
Task In progress,
Code review,
Quality assurance,
Done.
Additional information may be included on or attached to any kind of board:

Scrum Team members,
Sprint or event dates,
Definition of “Done,”
A burndown chart (progress and work remaining over time),
A parking lot (topics for future discussion).
Your candidate should mention that a Scrum Master is not obliged to provide the Scrum Team with a Sprint board. A board is the responsibility of the Development Team working with it. The Scrum Master should, however, support the effort with an introductory workshop on the subject if no member of the team is familiar with offline boards.

The Scrum Team is self-organizing. However, there are always moments when working on improving its practices is less of a Scrum Team’s priority. In this situation, a Scrum Master should follow up on the action items — tasks to be done — that members of a Scrum Team pick during their team’s Sprint Retrospective to remember everyone that Scrum is not working without self-organization.

A good way for a Scrum Master to do this is to start talking about the status of the action items picked during the last Sprint Retrospective before picking new ones by initiating a discussion at the beginning of each new Sprint Retrospective. (Note: This is not meant to be a reporting session but practical help to get self-organization going with the Scrum Team.)

Suppose this discussion uncovers action items picked during a previous Sprint Retrospective that haven’t been completed as expected. In that case, the team needs to understand why this happened and offer its support to prevent it from happening again.

The first critical issue for the majority of newly formed Scrum Teams is the existing legacy Product Backlog. Answers to this question need not reference Tuckman’s team development stages (see Question 28), additional team-building exercises, or any kind of Scrum training or workshop not concerned with the Product Backlog.

It is a rare occasion for a Scrum Master to start from scratch with a brand new team and no existing product — even more so in a nascent organization like a startup. Most often, it’s an existing product delivery organization with existing products and services that will ‘go agile’. For these cases, your candidate should point out that refining the legacy Product Backlog is the practical first step.

The legacy Product Backlog per se is an interesting artifact because it provides a comprehensive insight into the product delivery organization’s history: this particular Product Backlog allows for identifying organizational debt, process insufficiencies, questionable product decisions, and other anti-patterns.

Looking at a legacy Product Backlog, an excellent candidate will be able to point out some of these anti-patterns (e.g. outdated or poorly maintained tickets), and provide a good idea about how to transform the legacy Product Backlog into a well-refined, current Product Backlog such that a new Scrum Team could work with.

Candidates should mention that running Product Backlog refinement workshops creates a good opportunity to provide a new Scrum Team and Product Owner hands-on training with Scrum. This is because a Product Backlog refinement workshop will typically cover user story creation, knowledge transfer among team members, the estimation process (if applicable), introductory agile metrics, technical debt analysis, and other topics critical to the success of Scrum.

Time boxing means allotting a fixed unit of time for an activity. So the time is over activity is over – irrespective of the result. This brings in discipline, predictability and creates a situation for inspect and adapt. Every event in Scrum is time boxed which Must not be extended like Sprint, Daily Scrum etc.

Philosophies behind both frameworks are quite different. Kanban believes in delivering as soon as possible and it does not have time boxes like Sprints. However, Scrum believes in Time box oriented free collaboration among team members to come out with innovative solutions and work items. Scrum does not believe in Silos however Kanban may have silos.

Kanban focuses on WORK and Scrum focuses on Collaborative interaction among team members. Scrum speaks about mandatory roles and responsibilities however Kanban do not speak anything on roles so the implementation aspects are different.

• TO DO: You can do TKP (Team Kanban Practitioner Certification) and KMP1 (Kanban Management Professional) or KMP2 certification courses to know more on KANBAN and CSM (Certified Scrum Master Certification) or LSM certification courses to learn more or if you can spend time read books and try implementation

There are multiple approaches to it. Scrum has given SoS (Scrum of Scrums Model) which is very simplistic or there are quite a few situation specific and proven models like

SAFe ( Scaled Agile Framework )
Nexus
And many more
We can use anything suitable or even customize one for ours based on need and taking learning’s from above.

Scrum@Scale by Jeff Sutherland (Co-Creator of Scrum)

Agile Methodology refers to the software development process with an idea of iterative development between the self organised cross-functional team. The agile method emphasizes on breaking the whole process into different stages so as to keep track of every activity with constant collaboration resulting in improved and quality results at every stage of the workflow process. Keep reading scrum master interview questions.

With the concepts of Agile Methodology, teams are able to self organised themselves with the constant collaborative approach between the cross-functional team. Once the process of work begins, the teams need to go through different stages of planning, execution, evaluation and delivery.

The fundamentals of Agile Methodology relies on four core values:

1) Individual Interaction as well as Team Interaction over processes and tools.

2) Working Software over comprehensive documentation.

3) Customer collaboration over contract negotiation.

4) Responding to change over following a plan.

Communicating honestly and openly is the best way for a Scrum Master to get the cooperation of a Product Owner. Both must serve as servant leaders without being authoritative, and each depends upon the other working reciprocally for a Scrum Team’s success (e.g. accomplishing a Sprint’s Goal). They are allies with respect to coaching the organization to become, and remain, agile.

A Product Owner is responsible for providing prompt feedback on product matters, clarifying goals, and for ensuring that the entire product delivery team understands the product vision.

A Scrum Master, in return, supports the Product Owner in building a high-value, actionable Product Backlog, and to this end must facilitate effective collaboration between the Product Owner and the Scrum Team.


This question is meant to encourage an exchange of ideas about, and lessons learned when overcoming resistance to Scrum within an organization. Familiarity with agile failure patterns that are common to many organizations will demonstrate your candidate’s experience. (We have published a list of several agile failure patterns.)

Your candidate should also be familiar with the particular challenge middle managers face in any transition to agile practices. Moving from a command-and-control style (i.e. managing people and telling them what to do) to a servant-leadership style — thus abandoning Taylor’s principles — is not for everyone.

There are two principal reasons why a Scrum Team should be involved in the product discovery process as early as possible:

The sooner engineers participate in the product discovery process, the lesser the chances solutions will be pursued that are technically not viable or would not result in a return on investment.
Involving a Scrum Team early on ensures that the team and its Product Owner develop a shared understanding and ownership of what will be built.
This helps significantly with allocating resources to the right issues, maximizing value for the customer, and mitigating investment risk by maximizing the amount of low-value work not done.

Involving the Development Team members early in the process ensures their buy-in, and the team’s willingness to participate in all phases of a product’s development. This motivates the team to participate when making changes necessary to accomplish the Sprint Goals defined for each Sprint or product release.

The INVEST acronym was coined by Bill Wake and describes the characteristics of a good user story:

Independent. The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable. Until becoming part of an iteration, user stories can always be changed and rewritten.
Valuable. A user story must deliver value to the end-user.
Estimable. You must always be able to estimate the size of a user story.
Small. User stories should not be so big as to become impossible to plan, task, and prioritize with some certainty.
Testable. The user story (or its related description) must provide the necessary information to make test development possible.

A user story is a tool used in Agile software development that captures the description of a feature from an end-user perspective. It describes, among others, the type of users and their motivations. A user story creates a simplified description of a user’s requirements.