How would you handle a mandated Definition of Done with legacy debt?

WHAT THIS TESTS: This question tests whether you understand the Definition of Done as a living organizational standard that must be transparently aligned with reality, not a bureaucratic checkbox or a rigid rule to be circumvented. It probes your ability to balance Scrum commitments with technical debt, your courage to escalate uncomfortable truths, and your skill in building an incremental improvement plan rather than accepting permanent compromise.

A GOOD ANSWER COVERS: First, immediate transparency: you escalate the gap to the Product Owner and engineering leadership in the same Sprint, presenting data on which criteria fail and why. Second, a risk-based gap analysis: you categorize each unmet criterion by business risk, separating critical compliance or security gates from automation debt, so the organization understands the exposure. Third, a negotiated, time-bound remediation roadmap: you propose a Sprint-by-Sprint technical-debt backlog that incrementally raises team capability until it meets the organizational DoD, with clear milestones and explicit acceptance of interim risk by leadership. Fourth, strict separation of states: you never mark work as Done when it is not; instead you use clear labels for accepted risk or create a temporary, explicitly approved lower bar that is visible to all stakeholders. Fifth, process improvement: you embed the evolving DoD into team practices, using retrospectives to inspect progress and adjust the plan, treating the gap as a systemic impediment rather than a team failure.

COMMON WRONG ANSWERS: A major red flag is suggesting the team lower the bar quietly or ignore criteria to maintain velocity. Another is proposing overtime or squeezing work into future Sprints without negotiation, which masks the impediment and burns out the team. Saying the organizational DoD does not apply to legacy systems signals a lack of ownership. Claiming automated testing or security scans are impossible to implement also fails, because the question asks how you close the gap, not why you accept it.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle a Product Owner who pressures the team to mark items Done anyway, or how you quantify the business risk of unmet criteria. They might probe whether you would create a team-specific Definition of Done that differs from the organizational standard, and under what conditions that is acceptable. Expect questions about how you fund remediation when the Product Owner wants only features, or how you prevent the temporary gap from becoming permanent.

ONE CONCRETE EXAMPLE: Suppose the mandated DoD requires eighty percent unit-test coverage and passing static security analysis, but the legacy component has zero tests and a known dependency with critical CVEs. You would not ship and call it Done. Instead, you bring data to leadership: twelve critical CVEs, zero coverage, and an estimate of three Sprints to reach the standard if twenty percent of capacity is allocated to remediation. You negotiate a temporary exception for Sprint one with explicit risk acceptance by the PO and a signed roadmap, while immediately adding scanning and writing tests for all new code. By Sprint four, the team hits the standard and retires the exception.