Top 30 Agile & Scrum Interview Questions and Answers
30 multiple-choice questions on Agile & Scrum, of the kind that come up in a technical interview, drawn from 30 bites in the Agile & Scrum 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
A team's mandated project dashboard is replacing conversations about blockers. Which response best aligns with the Agile value of individuals and interactions?
Show the answer
Answer: a · Reduce mandatory fields, let the team own the board, and resolve blockers through direct conversation while keeping visibility.
The correct answer treats the tool as a servant for visibility while prioritizing direct human interaction to resolve blockers, matching the manifesto's intent. B is a tempting distractor because it misreads the value as anti-tool, ignoring the manifesto's caveat that processes and tools still have value.
Read the full bite: How does 'Individuals and interactions' shape team structure and communication?
Question 2 of 30
Which statement best reflects the Agile principle "Individuals and Interactions Over Processes and Tools"?
Show the answer
Answer: b · The primary focus should be on direct communication and collaboration, with processes and tools serving to enable these interactions.
This principle highlights that direct human communication and collaboration are more valuable than rigid processes or tools. While processes and tools are necessary, they should facilitate, not replace, these interactions. Option A is incorrect because it misinterprets "over" as "instead of," advocating for the complete removal of processes and tools, which is a common misconception.
Read the full bite: Individuals and Interactions Over Processes and Tools
Question 3 of 30
An Agile developer finds a bug. According to the value "Individuals and interactions over processes and tools," what is the most effective first step?
Show the answer
Answer: c · Talk directly with the relevant team member to quickly understand and verify the issue.
The principle prioritizes direct, high-bandwidth communication to solve problems efficiently. Talking directly is faster and more collaborative than creating a ticket (a process), which can introduce delays and misunderstandings.
Read the full bite: Individuals & Interactions Over Processes & Tools: Explain This Value
Question 4 of 30
A Scrum team holds a Sprint Retrospective. Which outcome best demonstrates that the event achieved its primary purpose?
Show the answer
Answer: d · The team inspected its processes and committed to at least one concrete adaptation for the next Sprint.
The retrospective's primary purpose is to inspect the team's process and adapt it through concrete improvements, not to review the product or vent. While discussing frustrations can be part of transparency, leaving without actionable adaptations misses the empirical pillar of adaptation that makes the event purposeful.
Read the full bite: Primary goal of a retrospective and its tie to continuous improvement
Question 5 of 30
What is the most crucial outcome of a successful Sprint Retrospective?
Show the answer
Answer: c · One to three actionable improvement items that are added to the next Sprint Backlog.
The primary purpose of a retrospective is to create a concrete plan for process improvement, making it a formal part of the team's work in the next sprint. Simply listing frustrations (Option D) without creating an actionable plan misses the core purpose of the event.
Read the full bite: Goal of a Retrospective and Continuous Improvement
Question 6 of 30
What is the primary goal of a Sprint Retrospective within the Scrum framework?
Show the answer
Answer: d · To inspect the team's process and create actionable plans for continuous improvement in the next sprint.
The Sprint Retrospective's core purpose is for the Scrum Team to inspect its process (people, interactions, tools) and create concrete, actionable plans for improvement in the upcoming sprint, driving continuous improvement. Option A is a common misconception, as the retrospective is not a forum for assigning blame but for collective learning and adaptation.
Read the full bite: What is the goal of a sprint retrospective?
Question 7 of 30
When an engineer applies the Agile principle of 'simplicity,' their main objective is to...
Show the answer
Answer: a · Maximize delivered customer value by identifying and focusing solely on essential features for the immediate need.
The principle of simplicity focuses on maximizing value by avoiding unnecessary work and delivering what is essential for the customer right now. Over-engineering for future needs (B) or passively accepting all requirements (D) goes against this principle, as does creating low-quality code (C).
Read the full bite: Explain 'Simplicity' and how you apply it as an engineer
Question 8 of 30
When asked to build a complex new feature, which action best demonstrates Agile simplicity?
Show the answer
Answer: d · Ship the thinnest end-to-end slice that validates user value before adding edge cases
Agile simplicity focuses on delivering the smallest end-to-end slice that proves user value while deferring unnecessary complexity. Skipping tests and documentation is a common misconception that mistakes simplicity for cutting corners, and collapsing logic into one file creates unmaintainable complexity rather than true simplicity.
Read the full bite: How would you apply Agile simplicity when implementing a new feature?
Question 9 of 30
When applying the Agile principle of simplicity, what is the team's primary focus?
Show the answer
Answer: b · Maximizing the amount of work not done by delivering only what is essential to solve the immediate problem.
Simplicity is defined as 'the art of maximizing the amount of work not done,' focusing effort on immediate value. Building a complex 'future-proof' solution is a form of over-engineering that this principle aims to prevent.
Read the full bite: Explain the Agile principle of Simplicity and how you apply it.
Question 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 of 30
After identifying deployment as the team's primary bottleneck, which action should you take first according to TOC?
Show the answer
Answer: a · Batch smaller deploys and pre-stage release checklists
Batching deploys and pre-staging checklists exploits the constraint by squeezing more throughput from existing resources before spending money, which is the second focusing step. Automating tests is elevation, which the card says must come only after exploitation and subordination.
Read the full bite: How do you identify and elevate your team's primary constraint using TOC?
Question 23 of 30
A software team identifies its code review process as the primary constraint. According to the Theory of Constraints, which action should they prioritize before considering hiring more reviewers?
Show the answer
Answer: a · Implement stricter coding standards and encourage smaller pull requests to improve review efficiency.
The Theory of Constraints (TOC) dictates that after identifying a constraint, the next step is to 'exploit' it by making the most of existing resources, such as improving review efficiency through better standards and smaller PRs (Option A). 'Elevating' the constraint, like hiring more reviewers (Option B), is a later step, only considered after exploiting and subordinating. Options C and D represent common misconceptions: focusing on local utilization or attempting to fix multiple bottlenecks at once, rather than the single primary constraint.
Read the full bite: How would you identify and elevate your team's primary constraint?
Question 24 of 30
A team identifies that its manual QA process is the primary constraint, with work consistently piling up. According to the Theory of Constraints, what is the most effective initial action?
Show the answer
Answer: b · Analyze and improve the existing QA process to maximize its current efficiency.
The first step after identifying a constraint is to 'Exploit' it—making the most of what you have. Hiring more people ('Elevate') is a later step, and improving a non-constraint (development speed) yields no system-wide benefit.
Read the full bite: How would you identify and elevate a team's primary constraint?
Question 25 of 30
A software team implements an Andon Cord for their main branch. Which action indicates a fundamental misunderstanding of its core principle?
Show the answer
Answer: d · The team creates a high-priority ticket for the developer who introduced the bug to fix it by the next stand-up.
The card explicitly states that creating a high-priority ticket, assigning individual blame, or scheduling the fix for later are common mistakes that miss the point of an Andon Cord. The principle requires an immediate, collective, all-hands-on-deck response, not a scheduled, individual task.
Read the full bite: How would you implement an Andon Cord for a software team?
Question 26 of 30
A CI pipeline fails on the main branch. According to the Andon Cord principle, what is the most appropriate immediate team response?
Show the answer
Answer: b · The entire team stops current work to swarm on diagnosing and fixing the problem.
The core of the Andon Cord is collective ownership and immediate response. The entire team swarms because build health is everyone's responsibility. While reverting might be the eventual fix, the first step is always to diagnose the root cause as a team.
Read the full bite: How would you implement an Andon Cord for a software team?
Question 27 of 30
A developer's commit breaks the integration test suite on trunk. According to Andon Cord principles, what is the most appropriate immediate response?
Show the answer
Answer: c · Halt the pipeline, block all merges, and have the team swarm to fix the root cause immediately
The correct answer reflects the automatic hard stop, merge blocking, and collective swarm for immediate root cause resolution that defines the software Andon Cord. Option A is tempting because reverting seems like a safe way to keep trunk green, but the card explicitly identifies reverting to fix in a branch later as a red flag that avoids collective ownership and stop-the-line discipline.
Read the full bite: How would you implement a software Andon Cord equivalent?
Question 28 of 30
In Scrum, who is ultimately accountable for deciding how much work from the Product Backlog can be included in a Sprint?
Show the answer
Answer: c · The Developers, as they are the ones responsible for creating the plan and doing the work.
The Developers are solely accountable for selecting the work for the Sprint Backlog, as they own the 'how'. While the Product Owner prioritizes the work, they do not dictate how much the Developers can forecast for a Sprint.
Read the full bite: What are the three Scrum accountabilities and their focus?
Question 29 of 30
Which statement accurately describes the distinct primary focus of the three accountabilities within a Scrum Team?
Show the answer
Answer: c · The Product Owner is accountable for maximizing product value, the Scrum Master coaches the team on Scrum, and the Developers create usable Increments.
The Product Owner's primary accountability is maximizing product value, the Scrum Master's is establishing and coaching on Scrum, and the Developers' is creating usable Increments. Distractors often misrepresent the Scrum Master as a project manager or team lead, or narrow the Developers' role to just coding or testing.
Read the full bite: What are the three accountabilities in a Scrum Team?
Question 30 of 30
Which statement accurately describes the Scrum Master's accountability as defined in the 2020 Scrum Guide?
Show the answer
Answer: a · Fostering an environment where transparency, inspection, and adaptation can thrive
The Scrum Master fosters an environment for empiricism rather than assigning tasks or controlling deadlines, which is a common misconception that confuses the accountability with project management. Ordering the backlog belongs to the Product Owner, and producing the Increment is the accountability of the Developers.
Read the full bite: Three accountabilities in a Scrum Team and their primary focuses
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.