"Done" sounds simple until a project is actually finishing, and different stakeholders reveal they had entirely different definitions the whole time.
Technical Completion and Business Readiness Are Different Things
Code being deployed and functioning correctly is a different milestone than the business actually being ready to use it effectively — conflating the two causes real confusion at exactly the moment everyone thinks they should be celebrating.
Acceptance Criteria Deserve to Be Specific, Not Vague
"It works" isn't a real, testable definition of done. Specific, testable criteria agreed upon before development starts prevent an entirely avoidable disagreement about whether a project has genuinely reached completion.
Some Work Is Legitimately Never Truly Finished
Ongoing products need a different definition of "done" than a discrete project — usually "this specific milestone is complete" rather than "the whole thing is finished" in any permanent, final sense.
A Practical Test
If you can't clearly state what specifically would need to be true for this project to be considered done, that's worth resolving before development even starts, not after everyone's already frustrated by an unresolved disagreement.
Starting a project and want crystal clear definition of done from day one? Custom Web Application Development
How to Handle Disagreement About Scope Right at the Finish Line
Late-stage disagreement about whether something is genuinely in scope usually traces back to an ambiguous original agreement, and resolving it fairly requires reviewing what was actually documented at the start, not just whoever argues most persuasively in the moment.
Establishing a clear process for handling exactly this kind of late-stage ambiguity, agreed upon before it actually arises, prevents the finish line from becoming an unexpectedly contentious negotiation that damages an otherwise successful working relationship.
Why "Done" Should Be Defined Differently for Different Project Types
A fixed-scope client deliverable, an internal process improvement, and an ongoing product feature all warrant genuinely different definitions of completion, and applying one universal standard across fundamentally different project types tends to produce a poor fit for at least some of them.
How Post-Launch Support Windows Should Factor Into the Definition
Agreeing explicitly on what happens after initial "completion" — a defined support period, a formal handoff process — prevents the awkward, unresolved question of whether ongoing minor fixes count as still being part of the original project or something new entirely.
A Reasonable Way to Document Definition of Done Upfront
A simple, written checklist of specific, testable criteria, agreed upon and referenced by both sides before development begins, gives everyone a shared, objective standard to evaluate against rather than relying on subjective judgment once the project nears completion.
How to Handle "Done" for Projects With External Dependencies
A project waiting on a third-party integration, regulatory approval, or another external factor outside direct control needs its definition of done to account for that dependency explicitly, rather than treating the entire project as stalled or incomplete due to something genuinely outside anyone's direct control.
Clearly separating what's actually within the team's control from what depends on an external party helps set more accurate expectations and prevents unfair frustration directed at a team that's completed everything within their actual power to complete.
Why "Good Enough to Ship" and "Fully Polished" Are Different Standards
Teams sometimes conflate shipping a genuinely usable version with shipping a fully polished, no-compromises version, when these are legitimately different, both valid standards depending on the situation — being explicit about which standard applies avoids a mismatch in expectations between stakeholders.
How Definition of Done Should Evolve for Iterative, Agile Projects
Agile methodologies define done at the sprint or feature level rather than the whole-project level, which requires a genuinely different mental model than traditional waterfall project completion, worth explicitly clarifying with stakeholders unfamiliar with iterative development approaches.
Why Documentation Completion Should Be Part of the Definition
A technically functioning feature without adequate documentation for whoever needs to maintain or use it going forward isn't genuinely complete in a practical sense, making documentation an explicit part of definition of done rather than an afterthought handled, if at all, after the "real" work is finished.
How Stakeholder Sign-Off Should Be Structured to Avoid Ambiguity
A formal sign-off process, with a specific named person confirming acceptance against the agreed criteria, prevents the ambiguous situation where a project seems informally accepted but no one has actually confirmed it meets the agreed definition of done.
Why Celebrating Completion Prematurely Can Create Real Problems
Declaring a project done before genuine stakeholder sign-off, purely to build momentum or satisfy an internal deadline, can create awkward situations if issues surface afterward that then feel like a regression from an already-celebrated finish line.
How to Handle Definition of Done for Projects Involving Multiple Vendors
When several vendors contribute to a single project, each vendor's specific completion criteria need explicit definition and coordination, since ambiguity about which vendor is responsible for which specific deliverable creates real risk of gaps nobody notices until the project is supposedly finished.
Why Retrospectives Should Include a Review of How Done Was Defined
Reviewing whether the original definition of done actually served the project well, as part of a post-project retrospective, helps teams refine their approach to defining completion criteria for future projects based on genuine lessons learned.
Why a "Done" Checklist Should Be Reviewed With Fresh Eyes Before Final Sign-Off
Having someone not deeply embedded in the day-to-day project work review the completion checklist with fresh perspective before final sign-off catches gaps that team members too close to the work sometimes overlook simply from familiarity.
Key Takeaways
- Technical completion and genuine business readiness are related but distinct milestones worth defining separately.
- Specific, testable acceptance criteria prevent avoidable late-stage disagreement about whether a project is done.
- Ongoing products need milestone-based completion definitions rather than a single, permanent "finished" state.
- Different project types warrant genuinely different definitions of done, rather than one universal standard.
- Agreeing on post-launch support scope upfront prevents ambiguity about what counts as still part of the original project.
Frequently Asked Questions
Should acceptance criteria be written before development starts?
Yes — specific, testable criteria agreed upon upfront prevent disagreement about completion that's far harder to resolve fairly after the fact.
How do we handle a project that seems like it will never truly be "done"?
Ongoing products benefit from milestone-based definitions of done, rather than expecting a single permanent finished state that doesn't genuinely apply.
What if scope disagreement arises right at the finish line?
Reviewing what was actually documented at the project's start, rather than relying on persuasive argument in the moment, resolves this most fairly.
Should post-launch support be defined as part of the original project scope?
Yes — agreeing explicitly on support window and handoff process prevents ambiguity about what counts as still part of the original engagement.
Is "it works" ever a sufficient definition of done?
Rarely — it's too vague to be genuinely testable, and specific, agreed criteria produce far less room for later disagreement.
How do we define done for a project with external dependencies?
Clearly separating what's within the team's control from external dependencies avoids unfair frustration about factors genuinely outside anyone's control.
Is there a difference between 'good enough to ship' and 'fully polished'?
Yes — both are legitimate standards depending on context, and being explicit about which applies avoids expectation mismatches.
Should documentation be part of the definition of done?
Yes — a functioning feature without adequate documentation isn't genuinely complete in a practical, maintainable sense.
Should project sign-off be formal, with a named responsible person?
Yes — formal sign-off prevents the ambiguous situation where a project seems informally accepted but nobody has actually confirmed it.
Is it risky to declare a project done before genuine sign-off?
Yes — issues surfacing afterward can feel like a regression from an already-celebrated finish line, creating awkward dynamics.
How do we define done for projects involving multiple vendors?
Each vendor's specific completion criteria needs explicit definition and coordination to avoid gaps nobody notices until supposedly finished.
Should someone outside the core team review completion before sign-off?
Yes — fresh perspective catches gaps that team members too close to the work sometimes overlook from familiarity.
Should we celebrate project milestones before the final completion?
Yes — celebrating genuine intermediate milestones sustains team morale without prematurely declaring the whole project finished.
Does project type affect how formal the done definition needs to be?
Yes — higher-stakes or client-facing projects generally warrant more formal, explicit definitions than smaller internal efforts.
Is it normal for the definition of done to change slightly during a project?
Some evolution is normal as genuine new information emerges, though major changes should be explicitly renegotiated, not quietly assumed.
Should we document lessons learned even for successful, smoothly finished projects?
Yes — documenting what worked well helps replicate that success intentionally in future projects, not just learning from failures.
Is a project retrospective still valuable if nothing seemed to go wrong?
Yes — capturing what worked well is just as valuable as capturing problems, helping replicate success intentionally.
Is a brief written summary better than a purely verbal project handoff?
Yes — a written summary creates a durable reference that a purely verbal handoff doesn't provide for future questions.
