How should the team address poor internal quality when stakeholders are happy?

What's really being asked

This question tests whether you treat Scrum as an empirical process or merely a project-management ritual. The interviewer wants to know if you understand that the Sprint Review inspects the Increment as a formal artifact, and that transparency about internal quality is mandatory for stakeholders. They are looking for the distinction between external feature acceptance and the actual state of the artifact, and whether you know that the Retrospective adapts the process while the Review adapts stakeholder understanding and the Product Backlog.

The full answer

First, at the Sprint Review, the Developers must make the poor internal quality and unsustainable practices visible to stakeholders. The Scrum Guide states that the emergent process and work must be visible to those performing the work as well as those receiving it, and that artifacts with low transparency lead to decisions which diminish value and increase risk. The team should explain that while the Sprint Goal was achieved, the resulting product or process has deviated outside acceptable limits. Second, the team should use the Review to inspect the increment honestly with stakeholders so that adaptation can occur; stakeholders may need to adjust ordering or expectations once they understand the drag created by the current approach. Third, at the Sprint Retrospective, the team inspects the specific process deviations that allowed internal quality to degrade and adapts by changing workflow, standards, or team agreements to prevent recurrence. Fourth, the answer should show courage: the team does not wait for permission to be transparent but treats hiding technical debt as a failure of empiricism.

The mistakes people make

A major red flag is suggesting the team should keep quality issues internal to avoid spoiling the stakeholder demo. This directly violates transparency and turns the Review into theater. Another red flag is conflating stakeholder happiness with increment acceptability; the Scrum Guide says if the resulting product is unacceptable, the process must be adjusted regardless of whether users are pleased with features. Saying the Product Owner alone decides quality is also wrong. Proposing to silently refactor in the next Sprint without informing stakeholders is another anti-pattern because it hides the true cost of work.

What usually comes next

The interviewer may ask how to make internal quality visible to non-technical stakeholders without losing their attention. They may ask what to do if stakeholders resist slowing feature work to address debt. They may also ask how the Definition of Done factors into this scenario, or at what threshold poor internal quality renders the increment unacceptable.

A concrete example

The team demos the new features and then presents a view of deployment frequency and test failure rates. They state that although the features work, the build now takes forty minutes instead of five and staging failures have doubled. They tell stakeholders that this deviation is outside acceptable limits and that the next Sprint must include process adaptation before new features are started. In the Retrospective, the team identifies that they skipped peer reviews to hit the goal and adapts by making reviews non-negotiable and adding a quality checkpoint before any item is considered done.