Scrum Master Interview Questions and Answers

Agile is a way of building software in small steps. The team delivers often, gets feedback often, and adapts to change.

The Agile Manifesto states four values:

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

The items on the right still matter, but the items on the left matter more. Twelve principles back these values. Examples are early and regular delivery, welcoming changing requirements, a steady work pace, and regular reflection.

What they are checking: Whether you know the basics, not just buzzwords

Scrum has three roles (called accountabilities) in one Scrum Team.

• Product Owner: makes the product as valuable as possible. They own and order the product backlog and speak for stakeholders.
• Scrum Master: makes sure Scrum is understood and used. They coach the team, remove impediments (blockers), and help run the events.
• Developers: the people who build a usable increment each sprint. This includes programmers, testers, and designers. They manage themselves and own the sprint backlog.

There is no project manager role or boss inside the team. A Scrum Team usually has ten people or fewer.

What they are checking: Whether you know the Scrum roles exactly

Scrum has five events.

• Sprint: a fixed period of one month or less. All the work happens inside it.
• Sprint planning: the team decides why the sprint is valuable (the goal), what can be done, and how to do it.
• Daily scrum: a 15 minute meeting. The team checks progress toward the sprint goal and adjusts the plan.
• Sprint review: the team shows the result to stakeholders and updates the product backlog.
• Sprint retrospective: the team looks at how it worked and plans improvements for the next sprint.

Each event is a chance to inspect and adapt. This is the core of Scrum.

What they are checking: Whether you can explain each event and its purpose

Scrum has three artifacts. Each one has a commitment.

• Product backlog: an ordered list of everything the product might need. Commitment: the product goal.
• Sprint backlog: the sprint goal, the chosen backlog items, and the plan to deliver them. Commitment: the sprint goal.
• Increment: a usable, joined-up step toward the product goal. Commitment: the definition of done.

Artifacts are transparent, so everyone has the same view of the work.

What they are checking: Whether you know the artifacts and their commitments

Agile is a mindset made of values and principles. Scrum is one specific framework that puts them into practice.

• Agile: a broad idea. Many methods follow it, such as Scrum, Kanban, XP, and Lean.
• Scrum: defines roles, events, artifacts, and fixed-length sprints.

You can be agile without Scrum, for example with Kanban. You can also use Scrum in a mechanical way, with meetings but no teamwork or change. That is not really agile.

What they are checking: Whether you can separate the idea from the framework

A user story is a short description of a feature from the user's point of view: "As a [role], I want [goal] so that [benefit]."

A good story follows INVEST:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

It also has acceptance criteria, often in Given/When/Then form. Example: Given I am logged in, when I click reset, then I receive an email within a minute. The talk around the story matters more than the card.

What they are checking: Whether you can write and judge stories

Story points are a relative unit for the size of work. They combine effort, complexity, and uncertainty. They are not hours.

• Teams use a Fibonacci-like scale (1, 2, 3, 5, 8, 13). They compare each story to reference stories.
• Velocity is the total story points of items fully done in a sprint. Only stories that meet the definition of done count.
• Average the last three to five sprints to forecast how much the team can take.

Velocity is a planning tool for one team. Do not use it to compare teams.

What they are checking: Whether you understand relative estimates and use velocity properly

The definition of done (DoD) is a shared checklist. An item must pass it to count as complete and ready to release. Acceptance criteria belong to one story only.

A story is done only when it meets both. A weak DoD causes hidden work and unusable increments.

What they are checking: Whether you can separate the shared quality bar from one story's needs

Sprint planning starts the sprint. The team decides what to build and how.

• Topic one: why is this sprint valuable? The Product Owner suggests how to add value, and the team agrees on a sprint goal.
• Topic two: what can be done? Developers pick backlog items based on their capacity and recent velocity.
• Topic three: how will the work get done? The team breaks the items into tasks.

Outputs: the sprint goal and the sprint backlog (the chosen items with a plan). The time limit is 8 hours for a one month sprint. It is shorter for shorter sprints.

What they are checking: Whether you can describe the planning flow

Kanban is a flow-based method. It shows work on a board and limits work in progress (WIP). Scrum works in fixed-length iterations.

Kanban suits support and maintenance work, where tasks arrive at random times. Scrum suits product work with planned increments. Scrumban mixes both.

What they are checking: Whether you can choose between them

No. The Scrum Master is a servant leader. They are accountable for how well the team uses Scrum.

Issue types: epic (a large body of work), story, task, bug, and sub-task.

A typical workflow is: To Do, In Progress, In Review (or Code Review), In Testing (QA), Done. Each status is a column on the board. Transitions can have rules. For example, you can require a resolution when an issue moves to Done.

They look at different things.

They are different sizes of work.

• Epic: a large body of work that spans several sprints. Example: "online payments".
• User story: a smaller piece of user value that fits in one sprint. Example: "pay by card".
• Task (or sub-task): the technical steps a developer does to finish a story. Example: "build payment API".

A sprint burndown chart shows remaining work (story points or hours) against the days of the sprint. An ideal line goes from the starting total down to zero.

Refinement is ongoing work on the product backlog. The team adds detail, estimates, and order so items are ready for coming sprints.

Planning poker is a way for the team to agree on relative estimates.

A sprint goal is one clear aim for the sprint. It gives the team focus and some flexibility. The team agrees on it in sprint planning. It stays fixed during the sprint, but the backlog items can be renegotiated.

A cross-functional team has all the skills needed to turn backlog items into a usable increment. These include development, testing, design, and operations.

The Scrum Master makes sure the event happens and stays within 15 minutes. The developers run it.

The SM teaches the team to focus on the sprint goal. They note impediments to follow up later. They stop outsiders from turning it into a status report. If the team can run it without the SM, that shows maturity.

MoSCoW sorts requirements into four groups.

• Must have: the release fails without it
• Should have: important but not vital
• Could have: nice to have if time allows
• Won't have (this time): agreed to be out of scope

A good retrospective is safe, structured, and ends in actions.

The Product Owner owns the product vision and the backlog. They decide what is built and in what order.

I make one dashboard for the team and another for stakeholders. I build them from JQL filters.

Team dashboard:

• Sprint burndown, sprint health, and issues by status
• Blockers filter: sprint in openSprints() AND flagged = true
• Bugs found vs fixed

Scaled agile frameworks help many teams work on one product.

Technical debt is the cost of shortcuts in design or code. It makes future changes slower and riskier.

I choose a small set of metrics that start useful talks.

Common anti-patterns (habits that look right but hurt the team):

Use the backlog size and the team's velocity to forecast a range.

A spike is a time-boxed research or prototype item. It reduces uncertainty. It does not deliver a user-facing feature.

A Scrum Master works inside one or two teams. They help the teams use Scrum day to day. An Agile coach works at a wider level: many teams, leaders, and the structure of the organization.

A scrum of scrums is a meeting to coordinate teams. One person from each team shares progress and dependencies.

Capacity is how much time the team has in a sprint. Velocity is how much work the team finished in the past.

• Capacity: team members times working days, minus leave, holidays, and meetings. Example: 5 people x 9 days x 6 focus hours = 270 hours.
• Velocity: points finished in past sprints (the average of the last few).

CI (continuous integration) means developers merge small changes often. Each merge starts an automated build and tests. CD (continuous delivery) means every change that passes can go to production, automatically or with one button.

A burnup chart shows completed work going up against a line for total scope. A burndown chart shows remaining work going down.

A definition of ready (DoR) is an optional team agreement. It lists what a backlog item needs before it enters a sprint: clear value, acceptance criteria, an estimate, known dependencies, and a design.

I choose based on how stable the requirements are, how fast feedback is needed, and how the team works. I do not choose by habit.

Treat it as learning, not blame. Then make the next sprint better.

Protect the sprint goal, but stay flexible for the business.

Start by asking why. Then help the team see the value. Do not just enforce rules.

For a support team with tickets that arrive at random, Kanban usually fits better.

Use the sprint goal and data to help both sides reach a decision.

Give them clear information through the artifacts. Do not interrupt the team.

Start small, train the team, and let them see benefits quickly.

Make it visible and escalate it with context.

I coach the person privately and change the format.