Practise explaining Agile and Scrum through product decisions, usable increments and learning. The questions cover foundational concepts, team flow and the coordination problems that appear when several teams share a product.
Product thinking: relate work to a goal and useful feedback rather than completing ceremonies.
Accountabilities: distinguish product ordering, the team’s plan and the work of enabling effective Scrum.
Adaptation: explain how evidence changes a plan and how flow measures inform improvement.
How to approach your answer
Start with the product goal and the uncertainty the team is trying to reduce.
Explain the relevant accountability or event, then show how it influences an actual decision.
Connect the decision to a usable increment, feedback and the next adaptation. Explain limitations honestly.
Two stakeholders call their work the highest priority.
Illustrative approach: I would make both requests and their expected value visible in the Product Backlog. The Product Owner is accountable for effective backlog management, including ordering; they can seek stakeholder input without transferring that accountability. The Developers plan how to achieve the Sprint Goal. I would help expose the trade-off and avoid side agreements that undermine the goal. A change during the Sprint needs discussion of its effect rather than automatic insertion as extra work.
Mistakes to avoid
Equating Agile with no planning or documentation.
Using velocity to rank individuals or compare teams with different contexts.
Describing Scrum events without connecting them to inspection and adaptation.
Questions and answer guidance
Start with the level closest to your experience. Each question links to its exact practice exercise; the answer is also available here without opening the app.
Foundations
Start with the concepts and explain them using a small example.
Technical · Fresher
1. Does Agile mean no documentation or planning?
Read the 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 the interviewer is assessing
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?
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 the interviewer is assessing
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?
3. How would you explain the difference between the Product Backlog and Sprint Backlog using a booking product?
Read the answer guide
I would explain it with a booking product. The Product Backlog is the ordered list of work to improve the product, such as a new payment option or better seat selection. The Sprint Backlog is the current Sprint's goal, the items the Developers selected and their plan for delivering them. The longer-term items stay clearly separate from that plan, so stakeholders do not think an item on the Product Backlog is a near-term commitment. Otherwise people assume everything listed will arrive soon, and the team is then blamed for work it never agreed to do.
What the interviewer is assessing
Whether you can explain the two backlogs simply, with a concrete example, and make clear that being on the Product Backlog is not a commitment.
Common mistakes
They say the Sprint Backlog is just a smaller copy of the Product Backlog, ignoring the Sprint Goal and the delivery plan.
They let stakeholders assume every Product Backlog item will be delivered soon, creating false commitments.
Practise a follow-up
Who owns each backlog and who can change them during a Sprint?
How would you handle a stakeholder who treats the Product Backlog as a promise?
4. What makes a delivery cycle adaptive when building an unfamiliar customer-service journey?
Read the answer guide
A cycle is adaptive when what we learn changes what we do next. In practice that means delivering or demonstrating a usable slice, such as a working first step of the customer-service journey, gathering evidence from real users, and then adjusting priorities or design. I would also name the decision the feedback can change, for example whether to simplify a form or drop a channel. Simply cutting a fixed plan into short intervals does not establish adaptation if the learning never alters priorities or design. The limit is that feedback must arrive early enough to matter.
What the interviewer is assessing
Whether you understand that adaptation means learning that actually changes priorities or design, not just shorter intervals, and can name the decision feedback is meant to influence.
Common mistakes
They describe a fixed plan split into short intervals as adaptive, even though nothing learned ever changes the priorities.
They gather feedback at the end of the cycle without saying which decision it could change.
Practise a follow-up
How would you choose the first usable slice for an unfamiliar journey?
What would you do if feedback arrives too late to change the plan?
5. Explain the difference between Agile and Waterfall, and when you would choose each.
Read the answer guide
Waterfall runs in sequential phases with the scope fixed early, which suits work with stable, well-understood requirements, strict compliance or heavy dependencies. Agile delivers in short iterations, gathers feedback often and adjusts the plan, which suits uncertain requirements and products that evolve. In practice most organisations blend the two, for example fixing the contract and milestones but delivering the work in sprints. The choice depends on how well the requirements are understood and how costly change is.
What the interviewer is assessing
Clear fundamentals plus a practical, balanced view.
Show how you would apply the idea to a constraint, disagreement or failure.
Technical · Mid-level
6. How do transparency, inspection and adaptation work in Scrum?
Read the 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 the interviewer is assessing
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?
7. Two stakeholders call their work highest priority. Who decides in Scrum?
Read the 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 the interviewer is assessing
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?
8. A team is pressured to commit to twice its recent capacity. How do you respond?
Read the 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 the interviewer is assessing
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?
9. Which metrics do you use to track an Agile team, and which do you avoid?
Read the answer guide
I use a few measures that help the team plan and improve: velocity as a planning aid for that one team, sprint goal success, cycle time and lead time, work in progress, defect escape rate and the trend in blocked items. I avoid comparing velocity between teams or using it as a performance target, because teams then inflate estimates and the number stops meaning anything. I also ask the customer and the team how they feel about delivery, since numbers alone miss trust and morale.
What the interviewer is assessing
Knowing what to measure and how metrics can be gamed.
Common mistakes
Comparing velocity across teams
Setting velocity as a target
Tracking many measures nobody uses
Practise a follow-up
Velocity has dropped for three sprints. What do you check?
How do you report Agile progress to a stakeholder who wants a fixed date?
Yes. Scrum provides the accountabilities, events and artefacts, and Kanban practices can help the team inside them. The team can visualise its workflow on a board, limit work in progress so items finish within the Sprint, and use flow metrics such as cycle time and aging to spot problems earlier than the Sprint Review would, which supports the Sprint Goal. What should not happen is dropping Scrum's events and roles and still calling it Scrum. The two fit together when each practice has a clear purpose.
What the interviewer is assessing
Whether you can combine Kanban flow practices with Scrum without losing Scrum's structure.
Common mistakes
Saying they are incompatible and a team must choose one or the other.
Adopting a board and calling it Scrum while dropping the Scrum events.
Practise a follow-up
How would a WIP limit fit into a Sprint Backlog?
Which flow metric would you bring to the Sprint Retrospective?
Explain trade-offs, wider consequences and the evidence behind your decision.
Technical · Senior
11. What changes when several teams share a product?
Read the 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 the interviewer is assessing
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?
12. How would you scale Agile delivery across several teams on one programme?
Read the answer guide
Start with the needs of the programme and not a framework. Align the teams around shared goals and a single prioritised backlog, and define clear team boundaries to reduce dependencies. Add light coordination such as a joint planning session each quarter or increment, a regular scrum of scrums, and shared definitions of done and integration testing. Frameworks such as SAFe or LeSS can give a starting structure, but adapt them to the organisation. Keep governance and funding models compatible with iterative delivery, or the teams will be forced back into fixed plans.
What the interviewer is assessing
Pragmatic understanding of scaling patterns and their limits.
Common mistakes
Adopting a framework because it is fashionable
Ignoring dependencies between teams
Keeping Waterfall governance on top of Agile teams
Practise a follow-up
Which coordination ritual would you introduce first?
How do you handle a fixed-price contract in this model?