Code Complete vs. Done: What's the Difference?

WHAT THIS TESTS: This question assesses whether you think in terms of value delivery or just task completion. Interviewers want to see if you understand that writing code is only one part of creating a potentially shippable product increment. It tests your grasp of team accountability, quality standards, and the core Scrum artifact that enables transparency and predictability: the Definition of Done.

A GOOD ANSWER COVERS: First, define 'Code Complete' as a developer-centric milestone. This means the code for a task is written, passes local checks, has unit tests, and is often ready for code review. It's an internal engineering signal, not a signal of customer value.

Second, define 'Done' as a team-wide, product-centric state. A Product Backlog Item (PBI) is 'Done' only when it meets all criteria to be considered part of a potentially shippable increment. It delivers value, is high quality, and is transparently finished.

Third, identify the 'Definition of Done' (DoD) as the key artifact. The DoD is a formal, explicit checklist that the entire Scrum Team agrees on. Any PBI that does not meet every item on the DoD is not 'Done'.

Fourth, articulate the gap. The work between 'code complete' and 'Done' often includes integration testing, passing end-to-end tests, documentation updates, security scans, performance validation, and sign-off from the Product Owner.

COMMON WRONG ANSWERS: Saying 'Done' means 'merged to main' or 'deployed to staging'. This is a major red flag. These are still technical steps, not a holistic measure of quality and value. It ignores crucial activities like QA, documentation, and ensuring the increment is actually usable.

Describing the Definition of Done as a document handed down by management. The Scrum Team creates the DoD. If one exists at an organizational level, the team adopts and may add to it. The team owns its quality commitment.

Failing to mention the 'Definition of Done' by name. This suggests a superficial understanding of Scrum processes.

LIKELY FOLLOW-UPS: Who is responsible for creating and upholding the DoD? (The entire Scrum Team).

What happens if a PBI isn't 'Done' by the end of the Sprint? (It is not demonstrated at the Sprint Review and is returned to the Product Backlog for re-estimation and re-prioritization).

How might a mature team's DoD evolve over time? (It becomes more stringent, incorporating non-functional requirements like performance benchmarks (e.g., p95 latency < 200ms), automated accessibility checks, and confirmed monitoring/alerting setup).

ONE CONCRETE EXAMPLE: For a PBI to 'Add OAuth login with Google', 'code complete' might mean the backend endpoint and frontend button are implemented and unit tested. The PR is open. For the same PBI to be 'Done' according to a team's DoD, it must also be: integrated and tested end-to-end, pass a security review for handling tokens, have its API documentation published, be verified by a QA engineer on multiple browsers, and have its usage tracked with an analytics event. Only then is it part of the valuable increment.