Scrum
312 bites tagged Scrum — interview questions with model answers, and 60-second explainers.
Why do teams use story points instead of hours or days?
Define against a baseline; explain they absorb uncertainty so velocity stabilizes for planning. You know points mean relative effort and complexity, not time. Equating points to hours or using them to rank individuals.
Explain backlog refinement: purpose, participants, and outcomes
Tests if you treat refinement as team-wide prep, not a solo PO task. Strong answers cite the full team and stakeholders, with outcomes being ready stories and estimates. Red flag: saying only the PO and Scrum Master attend or that it replaces sprint planning.
Two senior developers clash on implementation, derailing sprint planning. Your role?
Park or timebox the debate, reframe positions into shared interests with structured dialogue, and drive to a decision or spike. Protecting Scrum events while channeling conflict into productive tension.
Describe the difference between feature and component teams
Tests your grasp of how team structure affects value flow. A strong answer contrasts vertical slices with component ownership, noting feature teams shorten feedback while component teams create handoffs. Red flag: treating either as universally better.
How can developers support the Product Owner in backlog refinement?
Developers surface risks, sizing, and dependencies; co-create trade-offs; and split items early. Whether you treat refinement as a team activity or a PO hand-off. Developers who only estimate PO-written tickets.
What is a Scrum of Scrums purpose and what technical info is shared?
Multi-team sync for blockers, dependencies, API changes, integration risks; not a status meeting. Cross-team coordination in scaled Scrum. Treating it as a lead standup with PM-style updates.
How would you measure a launched feature's success and impact?
This tests if you link code to business outcomes via agile metrics. A strong answer covers value, quality, satisfaction; names metrics like velocity or cycle time; and uses reports to track progress. Red flag: defining success purely by uptime or bug counts.
Describe your role as an engineer in story refinement
Mention feasibility probes, acceptance criteria checks, and splitting for forecast clarity. Do you treat refinement as shared transparency or a PO handoff?
What user story details reveal the customer problem?
This tests if you see stories as problem placeholders, not specs. A strong answer asks for user role, action, 'so that' value, and confirmation criteria while demanding conversation. Red flag: listing technical tasks without mentioning the customer problem.
How should the team address poor internal quality when stakeholders are happy?
Tests whether you protect transparency when stakeholders are happy but quality is poor. Answer: At Review, expose the increment's real state—low transparency causes risky decisions; at Retro, inspect why quality degraded and adapt the process.
How would you shift a Sprint Review from demo to working session?
Tests if you see the Sprint Review as empirical inspection and adaptation with stakeholders. Strong answers reframe it around the Sprint Goal and Increment, gather live feedback on the Product Backlog, and adapt ordering together.
What action ensures a retrospective improvement is implemented?
Tests whether you treat adaptation as a deliverable. Propose making the top improvement a Sprint Backlog item with an owner and definition of done, then inspect it in the next retrospective. Vague agreements or more meetings without ownership are red flags.
Stakeholder rejects a completed feature in Sprint Review. Process and Backlog impact?
Tests whether you see Sprint Review as inspection or sign-off. Strong answers: welcome feedback as new data, keep the Increment Done, and have the Product Owner order new work into the Backlog. Red flag: extending the current Sprint to rework the feature.
What is the Sprint Retrospective output and what happens next?
Output is a concrete improvement plan enacted in the next Sprint, not parked. Whether you see Retrospectives as adaptation events or venting. Calling the output feedback with no action mechanism.
How would you handle a mandated Definition of Done with legacy debt?
Tests whether you treat the Definition of Done as a negotiable standard or a rigid rule, and if you know how to close the gap via transparency, incremental remediation, and organizational negotiation without shipping unfinished work.
How would you address a teammate working on misaligned low-priority tasks?
Tests whether you use the Daily Scrum to inspect progress toward agreed goals. Strong answers raise the misalignment at that event, adapt the plan as peers, and involve the Scrum Master only for environmental impediments.
How do you help establish a Sprint Goal when the PO hasn't?
Ask why the items matter, find a unifying outcome, and draft a goal the selected work supports. You know the Scrum Team defines the Sprint Goal together. Saying the PO alone owns the goal or starting tasks without coherence.
Explain the difference between code complete and Done. What artifact defines this?
Tests whether you know Done means a usable Increment, not just written code. Strong answer: code complete is a dev milestone; Done means the Increment meets quality standards. Red flag: saying testing happens after Done or that Done is optional.
Daily Scrum ticket updates: what primary purpose is missing?
This tests whether you know the Daily Scrum inspects Sprint Goal progress and adapts the plan rather than reporting status. A strong answer identifies the missing purpose as team inspection and adaptation against the Sprint Goal.
What is the Sprint Goal and how does it guide planning?
Goal-driven Sprints vs ticket batches. The Sprint Goal is the agreed objective guiding selection of ordered backlog items to build a valuable Increment and enable inspection. Red flag: calling it optional or pulling the top N items without negotiation.
What root causes and retrospective fixes address chronic sprint overcommitment?
Tests systemic diagnosis over blaming the team. Check capacity math, refinement quality, psychological safety, and stakeholder pressure; propose velocity-guided planning, capacity recalculation, and better refinement.
How would you break a large epic into sprint-ready user stories?
This tests decomposing scope into vertical, shippable slices. A strong answer maps user journeys, slices end-to-end functionality, applies INVEST, and sequences by risk and value. Red flag: horizontal layers like database, API, then UI.
What are the key components of a well-written user story?
Tests your ability to turn vague needs into actionable, testable work. A strong answer covers who, what, and why; defines acceptance criteria as specific, testable scenarios; and references INVEST.
How should the team handle a PO adding urgent work mid-sprint?
This tests your grasp of agreed goals and the Scrum Master role. A strong answer covers: inspecting the current work selection, negotiating swaps, and having the Scrum Master foster conversation.
Get Scrum bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.