Scrum Master / Agile Delivery Lead interview preparation
Use this guide to prepare for Scrum Master / Agile Delivery Lead interviews, with a focus on agile values, agile, sprint planning. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Agile values
Agile
Sprint planning
Daily Scrum
Empiricism
Agile scaling
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Technical · Fresher
1. Does Agile mean no documentation or planning?
Answer guide
No. The Agile values prefer working software over comprehensive documentation and responding to change over following a plan, but they do not say the items on the other side are worthless. Teams still plan, at several levels, and still write what people need, such as decisions, interfaces and operating instructions. The difference is that plans are treated as current best guesses that change with feedback, and documents are kept lean and useful. A regulated project, for instance, may need quite a lot of documentation and still be Agile.
What this question explores
Whether you read the Agile values accurately, as a matter of emphasis, not as a ban on planning.
Common mistakes
Saying Agile teams do not plan or write documents at all.
Quoting the values without being able to explain when documentation is still needed.
Practise a follow-up
Which documents would you keep in an Agile project and why?
How does Agile planning differ from following a fixed plan?
2. How would you govern funding for a product whose best solution is still uncertain?
Answer guide
I would fund bounded learning and delivery steps with clear outcomes, review points and options for continuation, rather than one large upfront budget. Cost stays visible and decision authority is clear, so each tranche has an owner. I would avoid both extremes: demanding premature certainty about a solution that is not yet known, and allowing indefinite investment without evidence of progress toward a worthwhile outcome. At each review the sponsor chooses to continue, adjust or stop. The trade-off is less predictability of total cost, which finance must accept in return for lower risk of wasted spend.
What this question explores
Whether you can govern uncertain investment through staged funding, evidence at review points and an explicit continue, adjust or stop decision.
Common mistakes
They demand a full fixed budget and detailed plan upfront for a solution nobody yet understands.
They release open-ended funding with no review points, so spend continues without evidence of progress.
Practise a follow-up
How would you size each funding tranche for an uncertain product?
How would you explain the unpredictable total cost to the finance team?
3. A team is pressured to commit to twice its recent capacity. How do you respond?
Answer guide
I would bring evidence to the conversation: the team's recent throughput, planned absences and the work already in flight. With the Developers, I would propose a Sprint Goal that is achievable and show what has to be left out to get it, making the trade-off explicit to whoever applies pressure. If the extra work is truly urgent, we discuss what to drop or how to reduce scope. Committing to double capacity does not produce double output; it produces cut corners, hidden debt and lost trust when the Sprint misses.
What this question explores
Whether you protect realistic planning with data and negotiate scope instead of accepting overcommitment.
Common mistakes
Agreeing to the larger commitment to please management, then hoping to work overtime.
Refusing flatly without offering evidence or alternatives on scope.
Practise a follow-up
How do you estimate capacity when the team has changed recently?
What would you do if leadership insists on the full scope?
The Daily Scrum is a short daily meeting for the Developers to inspect progress towards the Sprint Goal and adapt the plan for the next day. It is about the work and the goal, for example which items are blocked and who should pair up to finish something. It is not a status report to a manager or Scrum Master, and it does not have to follow three fixed questions. Keeping it to fifteen minutes at the same time and place makes it a regular habit that surfaces problems early.
What this question explores
Whether you understand it as the Developers' planning and adaptation meeting, not a status update.
Common mistakes
Describing it as each person reporting to the manager what they did yesterday.
Turning it into a long problem-solving meeting with everyone in the room.
Practise a follow-up
What can the team do when a topic needs more discussion than fifteen minutes?
Who should attend the Daily Scrum, and who may only listen?
5. How do transparency, inspection and adaptation work in Scrum?
Answer guide
Scrum rests on empiricism: knowledge comes from experience and decisions from what is observed. Transparency means the work, the Product Backlog and progress are visible and honestly described, using shared definitions. Inspection means examining the product and progress towards goals often enough to notice problems, through events such as the Daily Scrum and Sprint Review. Adaptation means changing the plan or the way of working when inspection shows a deviation. If any one is missing the loop breaks: hidden information cannot be inspected, and inspection without change has no effect.
What this question explores
Whether you can explain the three pillars as a feedback loop and how each depends on the others.
Common mistakes
Listing the three words without explaining how they work together.
Treating inspection as reporting to management rather than the team learning.
Practise a follow-up
Which Scrum event supports adaptation of the process itself?
What does a lack of transparency look like on a real team?
6. What changes when several teams share a product?
Answer guide
When several teams share a product, the hard problems become direction, dependencies and integration. I would keep one clear product direction and ordered backlog, agree a common quality bar and Definition of Done, and make sure the integrated product is built and tested often, ideally daily, not at the end. Reducing coupling through team-aligned ownership or clearer interfaces usually removes more coordination than a new ceremony does. Extra meetings are a cost, so I add them only for a specific problem and watch whether integration issues and delays fall.
What this question explores
Whether you address coordination through product clarity, integration and reduced coupling rather than more ceremony.
Common mistakes
Adding a layer of coordination meetings and roles as the first response to scale.
Letting each team integrate on its own schedule and discovering conflicts at release.
Practise a follow-up
How would you handle a dependency between two teams that keeps blocking delivery?
What structure changes could reduce coordination without adding meetings?
7. How should a Sprint Goal relate to a Product Goal?
Answer guide
The Product Goal is a longer-term objective for the product, and the Sprint Goal is the single coherent reason for this Sprint that moves towards it. Backlog items chosen for the Sprint are the means to reach the Sprint Goal, not the goal itself. This gives the Developers flexibility to adjust the work during the Sprint while still delivering value, and it helps stakeholders understand the purpose. If a Sprint Goal cannot be linked to the Product Goal, I would question whether the team is working on the right thing.
What this question explores
Whether you understand the hierarchy of goals and that backlog items serve the goal, not the reverse.
Common mistakes
Treating the Sprint Goal as just a list of selected backlog items.
Setting Sprint Goals that have no connection to the direction of the product.
Practise a follow-up
What should the team do when the Sprint Goal becomes obsolete midway?
A demo shows finished work; a Sprint Review inspects the Increment with stakeholders and uses what is learned to adapt the Product Backlog. The team and stakeholders discuss what was done, what changed in the market or the business, what to do next and how progress is heading towards the Product Goal. A demonstration may be part of it, but the aim is a working conversation and feedback, not a presentation. For instance, a stakeholder's comment can reorder the backlog for the next Sprint.
What this question explores
Whether you see the review as collaborative inspection that changes the plan, not a showcase.
Common mistakes
Treating it as a formal presentation where stakeholders just watch and approve.
Holding it without stakeholders, so no feedback reaches the backlog.
Practise a follow-up
How would you run a review when the Increment has little visible change?
Who decides whether the Increment is released after the review?
9. Retrospectives identify the same problem every Sprint. What would you change?
Answer guide
Recurring problems usually mean the retrospective produces talk without action. I would pick one small improvement, give it an owner and define how we will know it worked, then add it to the next Sprint so it is visible and inspected at the following retrospective. Where the cause lies outside the team, such as approvals or tooling, I would escalate with evidence of the effect on delivery. Changing the format can help too, but only if the outcome changes. Fewer, completed improvements beat a long list.
What this question explores
Whether you turn retrospective discussion into owned, measurable actions and escalate systemic blockers.
Common mistakes
Changing the retrospective format again and again without acting on the findings.
Writing a long action list that no one owns or reviews later.
Practise a follow-up
How would you handle a retrospective where people stay silent?
What evidence would show that a retrospective action really worked?
10. Why should a team have one Definition of Done?
Answer guide
A Definition of Done is the shared quality bar that an Increment must meet, such as coded, reviewed, tested, documented where needed and deployable. Having one standard for the whole product means everyone knows what done means, so progress is honest: work that does not meet it is not counted as done and returns to the backlog. If teams use different standards, integrating their work produces surprises and hidden unfinished work. The standard can be tightened over time as the team matures, and retrospectives are the natural place to do it.
What this question explores
Whether you see the Definition of Done as a transparency tool that keeps progress honest.
Common mistakes
Counting an item as done when only the coding is finished and testing is still pending.
Letting each developer or team keep a personal idea of what done means.
Practise a follow-up
What would you do if a team keeps missing its Definition of Done near the end of a Sprint?
How is the Definition of Done different from acceptance criteria?
11. Two stakeholders call their work highest priority. Who decides in Scrum?
Answer guide
In Scrum the Product Owner is accountable for ordering the Product Backlog, so the final call sits with them, though they should listen widely. My role, whether as Scrum Master or delivery lead, is to help the two stakeholders bring evidence to that decision: expected value, deadlines with real consequences, risk reduction and dependencies. Putting both cases side by side, ideally in a short session with the Product Owner, is better than each lobbying the team separately. The outcome and reasons are then made visible in the backlog so everyone understands the order.
What this question explores
Whether you respect Product Owner accountability while helping stakeholders make evidence-based cases.
Common mistakes
Letting the loudest or most senior stakeholder decide the order directly with the team.
Asking the Developers to choose between stakeholders, or splitting effort to please both.
Practise a follow-up
How would you help a Product Owner who cannot decide between the two?
What techniques could you use to compare value across competing items?
No. Velocity is a team's own planning aid and depends on how that team sizes stories, so one team's forty points may be another's twenty. Comparing teams invites inflated estimates and gaming, which destroys the number's usefulness. I would use it, cautiously, to forecast the same team's next few Sprints, and look at outcomes, flow measures such as cycle time, quality and customer feedback when discussing performance. If leadership needs a cross-team view, normalised business outcomes are far fairer than points.
What this question explores
Whether you know the limits of velocity and can redirect leaders to more meaningful measures.
Common mistakes
Ranking teams by points delivered, which pushes them to inflate estimates.
Treating a higher velocity as proof of better performance or more value.
Practise a follow-up
What measures would you offer leadership instead of comparing velocity?
How would you forecast a release when velocity is unstable?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.