Intermediate everything in Agile & Scrum, page 4
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.
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.
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.
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.
What is your responsibility when frontend developers are overloaded?
Tests cross-functional accountability and shared Sprint Goal ownership. Strong answer: own the goal collectively; pair, test, or learn simpler frontend tasks; raise the blocker at the Daily Scrum.
How should a Scrum Master resolve local optimizations hurting cross-team integration?
Tests if you see cross-team friction as a Scrum Master impediment needing global optimization. Answer: map the bottleneck, convene leaders to align on company goals, and broker a sustainable workflow. Red flag: blaming other teams or escalating without data.
How would you coach a developer skipping backlog refinement?
Coach one-on-one to find blockers; tie skipped refinement to planning delays; adapt format with the team.
Product Owner wants to change Sprint Backlog scope mid-sprint
This tests empirical adaptation and Sprint plan ownership. A strong answer says scope changes risk the Increment and agreed goals, so the team must inspect and adapt together. A red flag is treating the Sprint Backlog as a fixed contract immune to adjustment.
Describe your engineering contribution in backlog refinement and needed PO info
This tests if you treat refinement as collaborative planning. A strong answer covers feasibility feedback, sizing, dependency flags, and the business value or priority you need from the PO. Red flag: claiming engineers only receive requirements.
What is Definition of Ready and why must the PO uphold it?
Tests grasp of backlog refinement as a team agreement. Strong answers define ready as value, scope, and acceptance criteria; explain it stops mid-sprint churn; and cite dependencies mapped and designs attached.
Stakeholder approaches mid-sprint with a feature request. What is the Scrum process?
Tests whether you know the Product Owner orders the backlog and the Sprint selection is fixed. Strong answer: send the stakeholder to the PO, who decides placement. Red flag: adding the work to the Sprint Backlog yourself.
How is work selected and forecasted for the Sprint Backlog?
Tests empirical forecasting. Outline: the team selects from the ordered Product Backlog using observed experience and expertise to create one valuable Increment. Red flag: treating the forecast as a hard commitment or citing velocity as a required input.
How do items flow between the Product Backlog, Sprint Backlog, and Increment?
Tests whether you understand Scrum's three artifacts as commitments to value, not just task lists. A strong answer describes ordering, selection, and the Definition of Done. Red flag: calling the Sprint Backlog a task list owned by the Product Owner.
Describe the relationship between Jidoka and TDD/CI
Jidoka is stop-the-line; map TDD to unit detection and CI to build verification; show shift-left.
Explain Lean Muda and give three software lifecycle waste examples with mitigations
Tests mapping Lean waste to software with concrete countermeasures. A strong answer defines Muda as non-value-add work, cites three distinct types like waiting, defects, or overproduction, and pairs each with a specific practice.
How do you decide appropriate documentation levels without creating unnecessary overhead?
This tests balancing Manifesto values with operational reality. Strong answers define audience first, favor living docs over static artifacts, and calibrate depth to team topology and lifecycle stage. Red flag: using the Manifesto to justify no documentation.
AI Use Creates 'Cognitive Debt' in Scrum Teams
Over-relying on AI for sprint planning and backlog refinement creates "Cognitive Debt," eroding a team's problem-solving skills. While AI boosts productivity, it can eliminate the collaborative friction that builds shared understanding and critical reasoning.
How do you build a business case for technical debt?
This tests your ability to translate engineering problems into business impact. A strong answer quantifies the debt's cost (e.g., slower velocity), frames it as risk, and proposes a concrete payback plan like allocating 20% capacity.
Throughput vs. Velocity in Agile Planning
This tests your grasp of flow vs. estimation metrics. Define throughput as a count of delivered items and velocity as a sum of estimated points. Throughput measures actual output, making it better for forecasting. Red flag: claiming velocity is more accurate.
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