Top 30 Advanced Agile & Scrum Interview Questions and Answers
30 advanced multiple-choice Agile & Scrum interview questions, the deep end: internals, failure modes, and the design calls a senior engineer is expected to defend. They come from 30 bites in the Agile & Scrum library, the hardest 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
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 2 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 3 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 4 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 5 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 6 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 7 of 30
Which aspect of the Sprint container is most crucial for simultaneously enabling empiricism and protecting Developers?
Show the answer
Answer: b · Its fixed time-box, which establishes a regular cadence for inspection, and the Sprint Goal, which shields Developers from mid-Sprint scope changes.
The Sprint's fixed time-box creates a predictable cadence essential for inspection and adaptation (empiricism), while the Sprint Goal acts as a shield, preventing changes that would endanger it and thus protecting Developers' focus. Option A describes the 'what' of the Sprint but not the 'how' it enables empiricism or protection.
Read the full bite: How does the Sprint container enable empiricism and protect developers?
Question 8 of 30
Why does the fixed length of a Sprint matter most in Scrum?
Show the answer
Answer: c · It creates a predictable cadence of inspect-and-adapt points and protects the Sprint Goal
The fixed timebox is what makes empiricism work: regular inspection points and a locked Sprint Goal. It does not guarantee completion, nor does it license mid-Sprint scope changes.
Read the full bite: Why the Sprint is a 'container' for empiricism
Question 9 of 30
A stakeholder requests a significant new feature mid-sprint. How does the Sprint's structure primarily protect the Developers' ability to focus and deliver value?
Show the answer
Answer: d · By establishing an immutable Sprint Goal that cannot be endangered by new work.
The primary protection is the immutable Sprint Goal. While the Sprint Backlog can be renegotiated with the Product Owner, no change is made that endangers the Sprint Goal, ensuring the team remains focused on their objective. Forbidding all backlog changes is too rigid and incorrect.
Read the full bite: How does the Sprint container enable empiricism and protect developers?
Question 10 of 30
A Scrum Team discovers that work meeting their Definition of Done (DoD) consistently has performance issues post-release. How should they address this using Scrum's empirical process?
Show the answer
Answer: a · During the Sprint Retrospective, they should inspect their process and adapt their Definition of Done to include performance criteria.
The Sprint Retrospective is the correct event for inspecting the process (including the DoD's effectiveness). Adapting the DoD makes the new quality standard transparent and is the correct adaptation. The Sprint Review is for inspecting the product, not the process.
Read the full bite: Scrum Empiricism: Retro and Definition of Done
Question 11 of 30
Which description best explains why the Definition of Done and Sprint Retrospective must operate as a feedback loop rather than as separate practices?
Show the answer
Answer: b · The DoD creates a shared understanding of the Increment's actual state, enabling honest inspection in the Retrospective, which in turn adapts both process and the DoD itself.
The correct answer captures the systemic relationship: the DoD makes the Increment's true state visible (transparency), which allows the Retrospective to inspect process and adapt the standard itself if needed. Option A is tempting but wrong because the DoD is not one of the three formal Scrum artifacts, and the Retrospective does not validate release readiness.
Read the full bite: How do the Sprint Retrospective and Definition of Done support empiricism?
Question 12 of 30
Which statement best illustrates how the Sprint Retrospective utilizes the Definition of Done (DoD) to reinforce Scrum's empirical pillars?
Show the answer
Answer: a · The Retrospective inspects the effectiveness of the current DoD and adapts it to enhance transparency for future development efforts.
The Sprint Retrospective serves as the formal event for Inspection of the team's process, including the effectiveness of the DoD. Based on this inspection, the team then Adapts by refining the DoD itself, which directly improves Transparency for subsequent Sprints. Distractor D is a partial truth, as inspecting adherence is part of it, but it misses the critical aspect of adapting the DoD itself to improve transparency.
Read the full bite: How do the Sprint Retrospective and Definition of Done support empiricism?
Question 13 of 30
A Product Owner specifies a technical implementation detail. What is the most effective initial response for a Developer?
Show the answer
Answer: c · Express curiosity about the PO's underlying goal and present alternative solutions framed by business value.
The card stresses understanding the Product Owner's underlying goal and framing alternative technical solutions in terms of business value. Directly confronting the PO about their role or using technical jargon are identified as counterproductive approaches.
Read the full bite: How do you separate the 'what' from the 'how' with a Product Owner?
Question 14 of 30
A Product Owner includes a specific technical solution in a user story. What is the most effective initial action for a developer to take?
Show the answer
Answer: a · Ask the PO about the underlying needs or constraints that prompted their suggestion.
The correct approach is to first seek to understand the 'why' behind the PO's request, as they may have important context. Jumping directly to a counter-proposal without this understanding can miss key requirements and appear dismissive.
Read the full bite: How to handle a PO defining the technical implementation?
Question 15 of 30
During backlog refinement, the PO writes a story mandating a specific technical implementation. What is the most effective way for Developers to preserve autonomy while respecting Scrum accountabilities?
Show the answer
Answer: d · Reframe the story around the user outcome, propose the simpler solution with tradeoffs during refinement, and align on acceptance criteria together.
Reframing around the user outcome and proposing a simpler solution with tradeoffs during refinement preserves Developer autonomy while keeping the PO in control of value. Citing the Scrum Guide aggressively treats accountability as a weapon rather than a shared boundary and risks destroying trust.
Read the full bite: How do you navigate separating what from how with a prescriptive PO?
Question 16 of 30
In Scrum, if an Increment meets its acceptance criteria but fails to solve the user problem, which view on accountability best reflects empirical process control?
Show the answer
Answer: c · Accountability is shared but differentiated: the Product Owner adapts the backlog, Developers raise concerns during refinement, and the Scrum Master fosters inspection, using the Sprint Review to trigger adaptation.
The correct answer reflects Scrum's shared yet differentiated accountability and treats the Sprint Review as the empirical moment to inspect the increment and adapt the backlog immediately. Option A is tempting because the Product Owner is accountable for value, but isolating blame to one role ignores the collective ownership the entire Scrum Team has over the process.
Read the full bite: Where does accountability lie when acceptance criteria miss the user problem?
Question 17 of 30
An increment meets all acceptance criteria but is found to be useless to the user at the Sprint Review. What does this situation primarily indicate?
Show the answer
Answer: a · The Scrum process is functioning correctly by making a value-disconnect transparent, enabling the team to adapt.
This indicates Scrum is working as intended. The Sprint Review's purpose is to make value—or the lack of it—transparent so the team can inspect and adapt. Blaming the Product Owner ignores the shared accountability of the entire team to understand user needs.
Read the full bite: Who's accountable when an increment fails the user?
Question 18 of 30
When a Scrum Team delivers an Increment that fails to address the user's core problem, what approach best reflects shared accountability and systems thinking?
Show the answer
Answer: a · The entire Scrum Team should collaboratively examine their backlog refinement process and in-sprint feedback mechanisms for systemic improvements.
The card emphasizes that accountability for a valuable Increment is shared by the entire Scrum Team, and failures should be viewed as process issues, not individual blame. Option A focuses on collective analysis of upstream processes and feedback loops, aligning with the recommended approach. Option C, while seemingly helpful, incorrectly places sole blame on the Product Owner, which the card identifies as a common red flag.
Read the full bite: Accountability When an Increment Fails the User Problem
Question 19 of 30
You are asked to remove a three-week CAB process. Which strategy best demonstrates systems-level influence?
Show the answer
Answer: a · Map the change landscape for saturation, pilot Release on Demand with readiness-based governance, and validate via Release, Stabilise, Measure, Adjust
This reflects the card's approach of diagnosing change saturation, reframing governance around operational and people readiness, and piloting incrementally with evidence. Option C is tempting because automation is valuable, but it treats gates as malicious and ignores stakeholder readiness and transition planning.
Question 20 of 30
When attempting to change a deeply entrenched stage-gated release process, which initial action best aligns with an effective strategy?
Show the answer
Answer: c · Quantify the current process's impact on business value and developer efficiency using specific metrics.
The card emphasizes that the first phase of an effective strategy is to "diagnose and gather data" by quantifying the pain with metrics and business costs. The other options represent common pitfalls: a purely technical fix, a 'big bang' overhaul, or an adversarial stance, all identified as ineffective.
Read the full bite: Strategy for Changing a Stage-Gated Release Process
Question 21 of 30
As an engineering leader aiming to replace a slow, stage-gated release process, what is the most effective initial strategy?
Show the answer
Answer: a · Run a pilot program on a low-risk service, measure its impact on metrics like lead time, and use that data to persuade stakeholders.
The most effective strategy is to start small with a pilot, quantify the business impact with data (like lead time), and use that evidence to persuade. A top-down, big-bang migration is often too risky and ignores the need for cultural change.
Read the full bite: How would you change a mandatory, stage-gated release process?
Question 22 of 30
What is the primary role of a senior team member when facilitating a strong technical disagreement?
Show the answer
Answer: a · To ensure the team reaches a decision through a structured process, fostering commitment even without full consensus.
The card emphasizes that a senior's role is a neutral facilitator who guides a structured process to a decision the team can commit to, leveraging disagreement as "creative abrasion." Option D represents the "top-down authority" anti-pattern, which undermines a self-managing team.
Read the full bite: How does a team handle strong technical disagreements?
Question 23 of 30
Which approach best enables a self-managing team to resolve a strong technical disagreement without escalation?
Show the answer
Answer: a · Timeboxed dialogue phases with a neutral facilitator and multi-voting with written reasoning
The card describes structured timeboxed dialogue and multi-voting with reasoning as the core resolution process, with the senior developer acting only as a neutral facilitator. Option C is tempting because it references conflict mapping, but the facilitator must not impose the solution, as that violates self-management.
Question 24 of 30
A self-managing team is deadlocked over a key technical decision. As the senior developer, what is your most effective primary action to resolve the conflict?
Show the answer
Answer: b · Facilitate a structured process, like timeboxed dialogues, to guide the team to a decision.
The correct approach is to act as a facilitator, providing structure for the team to make its own decision. Making the final call yourself undermines the self-managing principle and team ownership.
Read the full bite: How does a self-managing team handle technical disagreements?
Question 25 of 30
A Scrum Team blames poor estimates for missed sprint goals, treats velocity as a target, and faces stakeholder pressure for more output. What systemic intervention should the Scrum Master prioritize?
Show the answer
Answer: b · Recalculate net capacity before planning, enforce a definition of ready, and treat historical velocity as a forecasting guide rather than a goal
Recalculating true capacity, enforcing a definition of ready, and using velocity as a planning guide address the systemic root causes of overcommitment. Hours-based tasking is tempting because the team blames estimates, yet it merely adds precision without fixing refinement quality, psychological safety, or stakeholder pressure.
Read the full bite: What root causes and retrospective fixes address chronic sprint overcommitment?
Question 26 of 30
A team consistently fails to complete about a third of their sprint backlog. What is the most effective initial action to resolve this overcommitment?
Show the answer
Answer: d · Use historical velocity data in the next retrospective to facilitate a team-led root cause analysis.
The most effective action is to diagnose the root cause with the team, not apply a band-aid. Using historical velocity data grounds the conversation in reality and helps uncover systemic issues like external pressure or poor refinement, which are the typical causes of overcommitment. Focusing only on estimation (B) ignores these deeper problems.
Read the full bite: How do you fix a team that consistently overcommits in sprints?
Question 27 of 30
When a Scrum team consistently overcommits, which approach best addresses the underlying systemic issues?
Show the answer
Answer: a · Facilitate a retrospective to analyze historical velocity, track actual capacity, and improve backlog refinement processes.
The correct approach focuses on systemic process improvements and data-driven insights, such as analyzing historical velocity and improving refinement, rather than blaming individuals or imposing top-down mandates. Conducting individual performance reviews (Option D) is a major red flag as it incorrectly attributes a systemic issue to individual performance.
Read the full bite: How do you fix a team that consistently overcommits?
Question 28 of 30
When addressing an unmanageable Product Backlog, which strategy best applies Scrum's empirical pillars?
Show the answer
Answer: c · Make bloat transparent, inspect items with stakeholders, and enable the Product Owner to re-order and cut
Making bloat transparent and empowering the Product Owner to re-order and trim waste reflects Scrum's pillars of transparency, inspection, and adaptation. Option D tempts teams eager to act quickly, yet bypassing the Product Owner violates the core accountability that the PO alone orders the backlog.
Read the full bite: What strategy would you propose to fix an unmanageable backlog?
Question 29 of 30
What is the most effective initial strategy for a senior team member to address an unmanageable 200-item product backlog?
Show the answer
Answer: a · Facilitate a dedicated workshop with the Scrum Team to re-anchor on the Product Goal and collaboratively triage items against it.
The most effective strategy involves a collaborative, goal-driven approach to drastically reduce the backlog. Option A emphasizes team involvement, re-establishing the Product Goal as a filter, and immediate, ruthless triage. Option D is a 'hero' answer, usurping the Product Owner's responsibility and lacking team collaboration, which is a common misconception.
Read the full bite: How do you fix a 200-item unmanageable product backlog?
Question 30 of 30
Your team's product backlog has over 200 items, making planning difficult. What is the most effective first step to address this systemic issue?
Show the answer
Answer: a · Propose a workshop with the team and Product Owner to define a clear, singular Product Goal to act as a filter.
The correct approach is to first establish a strategic filter (the Product Goal) to fix the root cause. Simply estimating all items is a tactical solution that doesn't address why the backlog became unmanageable.
Read the full bite: How would you fix a long, unmanageable product backlog?
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.