Top 30 Intermediate Agile & Scrum Interview Questions and Answers
30 intermediate multiple-choice Agile & Scrum interview questions, past the definitions: how the pieces fit together, what breaks in practice, and the trade-off behind a choice. They come from 30 bites in the Agile & Scrum library, the middle slice of the 369 Agile & Scrum interview questions in the library. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
Scrum, kanban, sprints, team velocity, shipping culture
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
Which approach best reflects the principle "working software over comprehensive documentation"?
Show the answer
Answer: c · Prioritize documentation that directly supports the software's value, like tests or API specs.
The principle is about prioritizing working software, not eliminating documentation. A good approach prioritizes documentation that adds value and evolves with the software, such as living documentation like tests or auto-generated API specs. Option D is a common misinterpretation, as documentation can be a valuable tool when it supports the software's value.
Read the full bite: How do you apply 'working software over comprehensive documentation'?
Question 2 of 30
A mature microservice platform with 15 dependent teams must reduce documentation maintenance overhead. Which strategy best applies the principle that documentation must earn its keep?
Show the answer
Answer: d · Archive low-traffic wikis, publish auto-generated API docs from code, and maintain curated human-written runbooks and onboarding guides
This approach calibrates documentation to audience size and lifecycle stage, favoring low-overhead generated specs while preserving human-written artifacts for high-value decisions like incident response. Option A is tempting because automation feels efficient, but generated specs alone cannot capture operational context such as runbooks and onboarding guidance.
Question 3 of 30
When determining the appropriate level of documentation for a new system, what is the most effective guiding principle?
Show the answer
Answer: a · Treat documentation as a product for a specific audience, weighing its creation cost against the future cost of its absence.
The correct approach is to treat documentation as a product with a specific audience and purpose, justifying its existence by ensuring its value outweighs its cost. While self-documenting code is valuable, it cannot capture architectural decisions or onboarding context, making that option incomplete.
Read the full bite: How do you decide the right level of project documentation?
Question 4 of 30
A team finds that many newly shipped features have very low user engagement. Which action best addresses this specific form of software development waste ('Muda')?
Show the answer
Answer: d · Prioritize the backlog based on direct user feedback and data.
This directly addresses the waste of 'Extra Features' by ensuring work is aligned with customer value, as per the YAGNI principle. Implementing WIP limits addresses bottlenecks and partially done work, not building unwanted features.
Read the full bite: Explain Muda (Waste) with three software development examples
Question 5 of 30
A team spends days merging branches, deploys frequent hotfixes, and maintains unused features. Which countermeasure set best targets the structural root causes of these three wastes?
Show the answer
Answer: b · Use trunk-based development with fast CI, test-driven development with automated regression, and hypothesis-driven MVPs with story slicing
The correct answer maps each waste to a structural Lean countermeasure: trunk-based development removes waiting caused by batching, TDD prevents defects before production, and MVPs stop overproduction by validating demand first. Option C is tempting because hiring staff and adding upfront documentation feel like responsible management, but they ignore Lean principles of flow and feedback loops and do not remove root causes.
Question 6 of 30
According to Lean principles, which activity is the clearest example of 'Muda' in software development?
Show the answer
Answer: d · Implementing features based on speculative future needs that are ultimately unused.
The card defines Muda as any activity that consumes resources but creates no value for the end customer. Implementing unused features (Extra Features) is explicitly cited as a form of Muda. The other options, while potentially inefficient if poorly executed, are generally considered necessary overhead or value-adding activities for long-term system health and collaboration, not pure waste.
Read the full bite: Explain the Lean concept of 'Muda' (Waste)
Question 7 of 30
What key technical foundation allows a team to implement frequent changes in a disciplined, Agile manner, rather than descending into chaos?
Show the answer
Answer: b · Loosely coupled architecture, high test coverage, and a mature CI/CD pipeline.
Disciplined agility relies on a technical foundation that makes change safe and cheap, such as loose coupling and CI/CD. A common misconception is that Agile is only about process; while backlog grooming is important, it doesn't technically enable safe, rapid change.
Read the full bite: Agile Change vs. Chaos: Technical Enablers
Question 8 of 30
Agile's principle of "welcoming change" is distinguished from chaotic development primarily by its reliance on what?
Show the answer
Answer: d · A robust framework of engineering discipline, including automated testing and modular design.
The card explicitly states that Agile's flexibility is a direct result of rigorous engineering discipline, highlighting practices like comprehensive automated testing, CI/CD, and modular architectural design. While frequent meetings and rapid iterations (Option B) are Agile practices, without this underlying technical discipline, they can lead to chaos rather than effective change management.
Read the full bite: How does Agile's 'welcoming change' differ from chaos?
Question 9 of 30
Which statement best describes how disciplined Agile teams keep changing requirements from creating chaos?
Show the answer
Answer: b · They combine collaborative feedback loops with engineering practices that make change cheap and safe.
The card emphasizes that Agile welcomes change through technical guardrails like automated testing, continuous integration, and evolutionary architecture, not just process ceremonies. Option A is tempting because it names real Agile practices, but the card explicitly warns that standups and sprints alone do not make change safe.
Read the full bite: How does Agile welcome changing requirements without chaos?
Question 10 of 30
How do TDD and CI practices most accurately embody the Lean principle of 'building quality in'?
Show the answer
Answer: b · They provide immediate feedback by halting the development or integration process as soon as a defect is detected.
The correct answer captures the essence of Jidoka ('stop the line'). TDD and CI build quality in by immediately halting the process upon failure, preventing defects from propagating. Option D is a secondary benefit, not the core principle, while Option A describes 'inspecting quality in', the opposite of the Lean ideal.
Read the full bite: Relate Lean's 'Build Quality In' to TDD and CI
Question 11 of 30
Which best describes how TDD and CI map to the Jidoka principle in software development?
Show the answer
Answer: d · TDD provides an early unit-level stop mechanism while CI provides an integration-level stop mechanism, embedding quality directly into the workflow.
This answer correctly identifies that TDD stops defects at the unit level and CI stops them at integration, together instantiating Jidoka's stop-the-line philosophy. The most tempting distractor is the first option because candidates often treat these practices as separate buzzwords rather than structurally equivalent feedback loops.
Read the full bite: Describe the relationship between Jidoka and TDD/CI
Question 12 of 30
Which statement best explains how Test-Driven Development (TDD) and Continuous Integration (CI) embody the Lean principle of 'Build Quality In' (Jidoka)?
Show the answer
Answer: c · They implement automated mechanisms that detect defects and immediately stop the process, preventing faulty work from moving downstream.
The core of Jidoka is the automated detection of a defect and the immediate stoppage of the process to prevent that defect from moving further. Both TDD (failing test stops development) and CI (failing build stops integration) directly implement this 'stop the line' mechanism. While increasing code coverage and reducing bugs (option A) are outcomes, they do not describe the specific 'stoppage' mechanism central to Jidoka.
Read the full bite: Relate 'Build Quality In' (Jidoka) to TDD and CI
Question 13 of 30
During Sprint Planning, how should Developers select Product Backlog Items to form the Sprint Backlog?
Show the answer
Answer: c · By crafting a Sprint Goal and then selecting the Product Backlog Items necessary to achieve that goal.
The Sprint Goal provides the 'why' for the Sprint, giving the work a cohesive purpose. Simply pulling items based on capacity (D) misses this crucial element of focus and value delivery.
Read the full bite: Relationship Between Product Backlog, Sprint Backlog, and Increment
Question 14 of 30
Which statement best describes how items move from the Product Backlog to the Sprint Backlog?
Show the answer
Answer: b · The Developers pull a forecast of Product Backlog items they believe they can complete to done during the Sprint.
The Developers own the Sprint Backlog and pull a forecast of items they believe they can finish to done during Sprint Planning. Option A is tempting because the Product Owner does order the Product Backlog, but they do not assign items into the Sprint Backlog.
Read the full bite: How do items flow between the Product Backlog, Sprint Backlog, and Increment?
Question 15 of 30
In Scrum, what is the primary purpose and commitment of the Sprint Backlog?
Show the answer
Answer: d · To provide a detailed plan created by the Developers for delivering the Sprint Goal, including selected Product Backlog Items and the work needed.
The Sprint Backlog is a plan created by the Developers during Sprint Planning to achieve the Sprint Goal, detailing the selected Product Backlog Items and the work required. Option B describes the Product Backlog, which is committed to the Product Goal, not the Sprint Backlog.
Read the full bite: Explain the Product Backlog, Sprint Backlog, and Increment
Question 16 of 30
In Scrum, how should the Scrum Team decide how much work to select for the Sprint Backlog during Sprint Planning?
Show the answer
Answer: a · By using their collective expertise and observed experience with the ordered Product Backlog items
The Scrum Guide defines Sprint Backlog selection as an empirical forecast based on the team's collective expertise and observed experience with the ordered Product Backlog. Citing velocity or capacity hours as required inputs is incorrect because the framework does not prescribe those tactics, and treating the forecast as a hard commitment contradicts Scrum's empirical foundation.
Read the full bite: How is work selected and forecasted for the Sprint Backlog?
Question 17 of 30
During Sprint Planning, who is ultimately accountable for deciding how many Product Backlog items are selected for the Sprint Backlog?
Show the answer
Answer: c · The Developers, because they are the ones who will be doing the work.
The Developers are solely accountable for selecting the amount of work for a Sprint, as they have the best insight into their capacity and the effort required. While the Product Owner prioritizes the work ('what'), they do not dictate how much is taken on ('how much').
Read the full bite: How does a team forecast work for a Sprint?
Question 18 of 30
Which approach best describes how a Scrum team forecasts work for a Sprint?
Show the answer
Answer: b · The Developers' selection of Product Backlog items, informed by past performance, current capacity, and the Sprint Goal.
The card emphasizes that Developers make the forecast, considering the Product Backlog, past performance, current capacity, and the Sprint Goal. Distractors incorrectly suggest a top-down mandate from a Product Owner or Project Manager, or an over-reliance on a single metric like velocity.
Read the full bite: How does a team forecast work for a Sprint?
Question 19 of 30
A stakeholder approaches a Developer mid-sprint with an urgent feature request. What is the most appropriate initial action?
Show the answer
Answer: b · Politely listen to understand the request, then direct the stakeholder to the Product Owner.
As a Developer, the correct first action is to listen to understand the request and then redirect the stakeholder to the Product Owner, who is solely responsible for managing the Product Backlog and prioritizing new work. Directly implementing the feature (option A) bypasses the Product Owner, endangers the Sprint Goal, and undermines Scrum principles.
Read the full bite: How do you handle an urgent mid-sprint feature request?
Question 20 of 30
A stakeholder directly asks you, a developer, to add a small but urgent feature mid-sprint. What is your most appropriate initial response?
Show the answer
Answer: b · Acknowledge the request and direct the stakeholder to discuss it with the Product Owner.
The Product Owner is solely responsible for prioritizing work and the Product Backlog. Redirecting the stakeholder to the PO is the correct process, while simply doing the work creates untracked 'shadow work'.
Read the full bite: How do you handle an urgent mid-sprint feature request?
Question 21 of 30
A stakeholder asks a Developer to add a new feature mid-Sprint. What is the correct Scrum response?
Show the answer
Answer: b · Direct the stakeholder to the Product Owner to discuss value and backlog placement
The Product Owner owns the Product Backlog and its ordering, so the Developer must route new requests to the PO rather than unilaterally adding work. Option A breaks the Sprint boundary by injecting work directly, while D confuses collective ownership with the PO's prioritization accountability.
Question 22 of 30
What is the primary purpose of establishing a 'Definition of Ready' for backlog items?
Show the answer
Answer: a · To ensure a backlog item is sufficiently understood and actionable before being accepted into a sprint.
The Definition of Ready is an upstream quality gate to ensure work is clear and valuable before a team commits. The most common distractor confuses this with the Definition of Done, which defines the criteria for an item to be considered complete at the end of a sprint.
Read the full bite: What is the Definition of Ready for a backlog item?
Question 23 of 30
During sprint planning, a story lacks acceptance criteria and a key external dependency is unresolved. Why should the PO uphold the Definition of Ready and pull a different item?
Show the answer
Answer: a · Because the Definition of Ready is a collaborative safeguard against mid-sprint churn from unclear scope and missing prerequisites.
The Definition of Ready is a lightweight team agreement that de-risks sprint planning by ensuring items are actionable before the team commits, stopping waste from unclear scope or missing dependencies. D is tempting because the PO does own backlog quality, but it wrongly recasts the standard as a rigid, bureaucratic gate rather than a collaborative flow safeguard.
Read the full bite: What is Definition of Ready and why must the PO uphold it?
Question 24 of 30
What is the primary purpose of establishing a Definition of Ready (DoR) for backlog items in an Agile team?
Show the answer
Answer: c · To ensure backlog items are sufficiently clear, understood, and prepared before a sprint begins, minimizing mid-sprint impediments.
The Definition of Ready (DoR) is a collaborative agreement ensuring backlog items are well-defined and prepared before a sprint, which reduces ambiguity and prevents mid-sprint issues. It is distinct from the Definition of Done, which is an exit criterion, and is a widely adopted practice, not a mandatory Scrum Guide element.
Read the full bite: What is the 'Definition of Ready' for a backlog item?
Question 25 of 30
Which statement best describes an engineer's primary responsibility during product backlog refinement?
Show the answer
Answer: c · To collaborate on clarifying requirements, decomposing work, and identifying technical risks.
The engineer's role is proactive, focusing on collaboration to clarify, decompose, and de-risk work for future sprints. Committing to work happens in Sprint Planning, not refinement.
Read the full bite: Your Role in a Product Backlog Refinement Meeting
Question 26 of 30
Which action best demonstrates a senior engineer's proactive contribution during backlog refinement?
Show the answer
Answer: c · Proposing to break down a complex user story into smaller, deliverable tasks, identifying technical dependencies, and explaining the rationale behind effort estimates.
A senior engineer proactively shapes the work by adding technical detail, splitting stories, and explaining estimates, which de-risks projects and ensures efficient delivery. Simply listening and clarifying requirements (Option A) represents a more passive, junior mindset rather than active ownership in shaping the work.
Question 27 of 30
Which behavior best demonstrates an engineer's collaborative role during backlog refinement?
Show the answer
Answer: d · Probing acceptance criteria, providing rough sizing, surfacing dependencies, and requesting business context
Option D is correct because effective refinement requires engineers to actively clarify scope, forecast effort, expose constraints, and seek business value and priority from the Product Owner. Option A is tempting but wrong because turning refinement into a full design session contradicts the Scrum goal of preparing items just enough for sprint selection rather than finalizing implementation details early.
Read the full bite: Describe your engineering contribution in backlog refinement and needed PO info
Question 28 of 30
During a Sprint, the Product Owner proposes replacing a Sprint Backlog item after learning of a new requirement. What should the Scrum Team do?
Show the answer
Answer: b · The Developers and Product Owner inspect the change's impact on the Increment and agreed goals, then adapt the plan if warranted.
Developers and the Product Owner must inspect the change together and adapt only if the Increment and agreed goals remain viable. Option D is tempting but wrong because the Sprint Backlog is a forecast, not a fixed contract, and empiricism requires responding to new learning rather than freezing scope.
Read the full bite: Product Owner wants to change Sprint Backlog scope mid-sprint
Question 29 of 30
A Product Owner requests adding a new, high-priority item to the current sprint. What is the most appropriate initial response from the Developers?
Show the answer
Answer: b · Assess if the new item jeopardizes the Sprint Goal, and if not, negotiate removing an existing item of comparable size.
The correct approach involves first assessing if the Sprint Goal is at risk. If not, the Developers should collaboratively negotiate changes to the flexible Sprint Backlog by swapping items of similar size to maintain focus. Simply checking capacity (A) or passively accepting (D) risks the Sprint Goal and team focus, while a rigid refusal (C) misunderstands Scrum's adaptive principles.
Read the full bite: Changing Scope Mid-Sprint: Consequences and Conversations
Question 30 of 30
A Product Owner requests adding a significant new feature mid-sprint. What is the Development Team's most appropriate initial action?
Show the answer
Answer: d · Assess the new work's impact on the Sprint Goal and then discuss trade-offs with the Product Owner.
The team's primary commitment is to the Sprint Goal. The first step is to assess if a change jeopardizes that goal. While swapping items is a valid negotiation tactic (making A a tempting distractor), it's a secondary step that can only occur after the impact on the goal is understood.
Read the full bite: Handling Mid-Sprint Scope Change Requests
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.