Handling a Mandated DoD on a Legacy System

WHAT THIS TESTS: This question tests pragmatism, leadership, and a commitment to quality. The interviewer wants to see if you can navigate the conflict between a top-down standard and a bottom-up reality. They're testing your ability to make problems transparent, create a concrete improvement plan, and avoid simply asking for a permanent exception. It's a test of your ability to influence upwards and lead your team out of a difficult situation, not just manage it.

A GOOD ANSWER COVERS: A strong answer hits four key points in order. First, acknowledge the organizational standard as the "true north" and don't argue against its value. Second, work with your team to create a current team-level Definition of Done that is realistic and can be met for every single item in the Sprint. This ensures predictability. Third, make the gap between the team's DoD and the organization's DoD transparent. This gap represents undone work and is a form of technical debt. Fourth, create a concrete, measurable plan to close that gap over time. This means creating specific backlog items to address the tech debt (e.g., "Add integration tests to the billing module") and dedicating a percentage of sprint capacity (e.g., 15-20%) to this work until the team's DoD matches the organizational one.

COMMON WRONG ANSWERS: A major red flag is asking for a permanent exception for your team, which signals an acceptance of lower quality. Another is ignoring the organizational DoD and just creating your own without a plan to align. A third weak answer is to try and meet the full DoD on a "best effort" basis, which leads to unpredictable delivery and defeats the purpose of having a DoD. The goal is consistency and transparency, not "mostly done."

LIKELY FOLLOW-UPS: Expect questions like: "How would you get buy-in from the product owner to spend capacity on this 'non-feature' work?" (Answer: Frame it as reducing risk, increasing future velocity, and ensuring the product is truly releasable). "What if management pushes back and says you must meet the standard now?" (Answer: Show them the data on what it would cost in terms of feature delivery and propose a realistic, incremental plan as the lower-risk option). "How do you make this 'undone work' visible?" (Answer: Use specific ticket types, a separate swimlane on the board, or a technical debt burndown chart).

ONE CONCRETE EXAMPLE: Let's say the organizational DoD requires 90% code coverage, but our legacy component is at 40%. Our team's current DoD could be "All new code has 90% coverage, and the overall coverage for the component does not decrease." We then create backlog items to add tests to specific, high-risk legacy modules. We allocate 15% of each sprint's capacity to these items. We report our progress on closing the coverage gap from 40% to 90% to stakeholders each quarter, demonstrating our commitment to reaching the organizational standard.