Intermediate interview questions in Agile & Scrum, page 7
Why do teams use story points instead of hours or days?
Define against a baseline; explain they absorb uncertainty so velocity stabilizes for planning.
Explain story points vs. time-based estimation.
This tests your grasp of Agile philosophy. A good answer defines points as relative effort (complexity, volume, risk), contrasts this with the pitfalls of time, and links it to predictable team velocity. A red flag is mapping points directly to hours.
Explain story points and why they're used over time-based estimates
Tests your grasp of relative vs. absolute estimation. Define story points as a relative measure of effort, complexity, and uncertainty. Explain they foster team consensus and provide a more stable velocity than time-based estimates.
What is the primary difference between Sprint Review and Sprint Retrospective?
Tests separation of product feedback from process improvement. Review: stakeholders inspect the Increment and adapt the backlog. Retrospective: Scrum Team only inspects its process and plans improvements. Red flag: calling either a status report or demo.
Sprint Review vs. Retrospective: Purpose and Participants
This tests your understanding of Scrum's dual feedback loops for product versus process. A great answer defines Review as inspecting the Increment with stakeholders, and Retrospective as inspecting the team's process without them.
Sprint Review vs. Sprint Retrospective: Purpose and Participants
Tests if you distinguish inspecting the product (Review) from the process (Retro). A good answer defines purpose (what vs. how), participants (stakeholders vs. team-only), and outcomes (backlog vs. process improvements).
How do you spike a story to de-risk it and define deliverables?
Whether you see spikes as time-boxed research, not feature work. Propose a fixed duration, define the specific question, deliver a decision record or prototype, and revise the story estimate. Never treat a spike as production code or skip the time box.
How would you use a spike to de-risk a story?
Tests your use of Agile spikes for de-risking, not for building features. A good answer defines the goal, sets a strict time-box, and clarifies the deliverable is knowledge (e.g., a POC), not production code. A red flag is merging spike code into main.
How do you use a spike to de-risk a story?
This tests your ability to use agile spikes for targeted de-risking, not just vague research. A strong answer defines the specific question the spike will answer, proposes a strict time-box, and lists concrete deliverables like a decision or a better estimate.
What is the primary purpose of a WIP limit in Kanban?
Tests whether you see Kanban as a flow system, not just a board. A great answer says WIP limits constrain multitasking to reduce cycle time and improve throughput by prioritizing finishing over starting. Red flag: saying limits are for tracking progress.
What is the purpose of a WIP limit in Kanban?
Tests understanding of Kanban flow optimization. A good answer explains that WIP limits force task completion, which improves flow, reduces context switching, and exposes bottlenecks. A red flag is describing it only as a way to prevent team burnout.
Purpose and Consequences of Kanban WIP Limits
Tests your grasp of flow efficiency. A good answer defines WIP limits as a tool to manage system flow, expose bottlenecks, and create a pull system, then links ignoring them to cascading delays. A red flag is seeing them as a tool to micromanage individuals.
Explain Little's Law and its practical application in Kanban
This tests your grasp of the WIP-throughput-lead time relationship in stable flow systems. State Lead Time = WIP / Throughput and show lowering WIP cuts lead time if throughput is flat. Beware claiming more WIP raises throughput without increasing lead time.
Explain Little's Law and its application in Kanban
Tests your grasp of flow metrics beyond the formula. A great answer defines the law (Lead Time = WIP / Throughput), explains the trade-offs (e.g., more WIP increases lead time), and shows how to set WIP limits.
Explain Little's Law and its application in Kanban
Tests your grasp of flow metrics. A good answer defines the formula (Lead Time = WIP / Throughput), explains the trade-offs, and gives a practical example. A red flag is ignoring the prerequisite of a stable system, which makes the formula's output…
From an engineer's perspective, when does Cycle Time begin and end?
Tests if you set Cycle Time boundaries to expose wait states past coding. Strong answer: starts at In Progress, ends at Done or production, includes review/test, excludes backlog queues, and distinguishes from Lead Time. Red flag: starting at ticket creation.
When Does Cycle Time Begin and End?
This tests your grasp of process metrics. Define Cycle Time as starting when active work begins ('In Progress') and ending when it's 'done' (code complete/merged), not when the ticket was created. A red flag is confusing this with customer-facing Lead Time.
When does a task's Cycle Time begin and end?
This tests your practical grasp of process metrics. Define Cycle Time as starting when active work begins ('In Progress') and ending when 'Done' (shippable). Contrast it with Lead Time (request to delivery). A red flag is confusing the two or being too vague.
How would you probabilistically forecast 40 stories using throughput data?
Tests probabilistic forecasting literacy using historical throughput. Good answers gather 8–12 periods of throughput, run Monte Carlo resampling, and present percentile delivery curves (e.g., 50th/85th/95th).
How would you create a probabilistic forecast for 40 stories?
This tests your ability to use statistical methods for forecasting. A great answer explains how to use historical throughput in a Monte Carlo simulation to generate a probability distribution of completion dates, not a single point estimate.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles