Code Complete vs. Done: What's the Difference?
Tests your understanding of value delivery vs. task completion. A great answer defines 'code complete' as a developer milestone and 'Done' as a team-agreed state of shippable value, governed by the Definition of Done.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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).
A 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.
Interview question
What is the key difference between a feature being 'code complete' and being 'Done'?
- a.'Code complete' is a developer milestone, while 'Done' means the feature meets the team's full Definition of Done and is potentially shippable.Correct
- b.A feature is 'code complete' when it passes unit tests, and 'Done' when it passes all QA tests.
- c.A feature is 'code complete' when the code is written, and 'Done' when it is merged to the main branch.
- d.They are interchangeable terms; different teams use them to signify that development work is finished.
Why? this is the answer
'Done' is a team-wide quality standard defined by the Definition of Done, ensuring a feature is valuable and potentially shippable. Being 'code complete' or merged to main are just intermediate steps in that process.
Just read this? Test yourself on what you have been reading.
Read the original → scrumguides.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles