How do you handle a PO adding work mid-sprint?
This tests your ability to protect the Sprint Goal collaboratively. A good answer acknowledges the PO's intent, proposes a scope swap to make trade-offs visible, and uses the Retrospective for long-term fixes.
WHAT THIS TESTS: This question tests your practical application of Scrum principles beyond just reciting the rules. It's assessing your ability to handle scope creep, negotiate trade-offs, and use the framework's own mechanisms (like Retrospectives) to solve process problems. The interviewer wants to see if you can protect your team's focus and predictability while still being a collaborative partner to the business, represented by the PO. It’s a test of pragmatism over dogmatism.
A GOOD ANSWER COVERS: A strong answer has four parts. First, acknowledge the PO's position and the validity of their goal to maximize value. Second, clearly state the impact of the new work on the current Sprint Goal, making the risk transparent. Third, propose a concrete, immediate solution: a scope swap. Offer to trade the new item for an item of equivalent size already in the sprint. This makes the cost of the change explicit. Fourth, suggest a long-term process improvement by using the next Sprint Retrospective to discuss this pattern and find a systemic solution with the PO and Scrum Master.
COMMON WRONG ANSWERS: A major red flag is being overly rigid and just saying 'No, the Scrum Guide says you can't change the sprint.' This shows a lack of collaboration. Another is being a pushover and just accepting the work, leading to burnout and missed commitments; this signals an inability to manage process. Blaming the PO personally is also a bad sign. The focus should be on the process and the shared goal, not on individual fault. Finally, immediately escalating to the Scrum Master without first trying to have a direct conversation with the PO is a weak move.
LIKELY FOLLOW-UPS: 'What if the PO insists it's a 'must-do' and refuses to swap anything out?' (Answer: This might be a reason to cancel the sprint, an extreme but valid Scrum option if the Sprint Goal becomes obsolete). 'How would you prevent this from happening in the first place?' (Answer: Better backlog refinement, more proactive communication with the PO about upcoming business needs). 'What if this happens every single sprint?' (Answer: The team could formalize a process, like reserving 10-15% of sprint capacity for unplanned, high-priority work).
ONE CONCRETE EXAMPLE: 'In a 2-week sprint where we committed to 40 story points, our PO asked to add an urgent 5-point story on day 3. I would say, "I see this is critical. To protect our Sprint Goal and not risk a partial delivery, we need to swap. We can pull in this 5-point story if we move the other 5-point story X back to the Product Backlog. Does that trade-off work for you?" This makes the cost immediately clear and respects both the PO's need for agility and the team's need for focus.'
Read the original → scrumguides.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.