How to Handle Poor Quality with Happy Stakeholders?

What's really being asked

This question tests your understanding of the Scrum pillar of Transparency and your ability to use Scrum events for their intended purpose, even in socially difficult situations. The interviewer wants to see if you prioritize long-term sustainability and honest stakeholder collaboration over short-term 'wins.' They are testing if you see Scrum as a risk-management framework, not just a feature-delivery process.

The full answer

A good answer covers four key points. First, in the Sprint Review, the team must be transparent about the poor internal quality. Frame it as a risk to future velocity and sustainability, not a failure. Second, present stakeholders with a concrete trade-off and a proposed plan, for example, allocating 20% of the next Sprint's capacity to address technical debt in exchange for fewer new features. This makes the cost of poor quality visible. Third, in the Sprint Retrospective, the team must inspect its own process to find the root cause. Was the Definition of Done ignored? Was there too much pressure? The goal is to identify a specific process improvement for the next Sprint. Fourth, a senior answer mentions the Scrum Master's role in facilitating these conversations and upholding Scrum values.

The mistakes people make

The most common red flag is suggesting the team should hide the problem from stakeholders during the Sprint Review and only discuss it internally in the Retrospective. This violates Transparency and leads to stakeholders making decisions based on false information. Another wrong answer is blaming the Product Owner or stakeholders. A mature answer focuses on shared ownership and a constructive path forward. Finally, avoid vague commitments like 'we'll try to write better code.' A senior answer includes specific, actionable proposals like updating the Definition of Done or formally allocating story points to refactoring.

What usually comes next

Expect follow-ups like: 'What if the Product Owner insists you don't mention the quality issues to the stakeholders?' (This tests your understanding of the Scrum Team's collective ownership and the Scrum Master's role in coaching the PO). Or, 'How would you change your Definition of Done to prevent this from happening again?' (This probes for concrete technical and process improvements).

A concrete example

A great response might say: 'In the Review, I'd explain that while we met the goal, we incurred significant technical debt, which is like taking a high-interest loan. To maintain our pace, we need to start paying it back. We propose dedicating 10 story points in the next Sprint to refactoring the checkout module. In the Retro, we'd discuss why this happened and likely add a checklist item to our Definition of Done requiring a certain code coverage percentage before any story can be considered Done.'