A task can look finished to the person doing it and incomplete to the person receiving it. The difference often appears late, when someone asks for a missing approval, a different file format, supporting photos, or a handoff that nobody planned. Work then reopens even though effort was already spent.
Defining done is a short alignment practice: describe the observable outcome, the quality bar, the evidence, and the person who accepts it. The goal is not to predict every detail. It is to replace private assumptions with a finish line the people involved can recognize before work begins.
Describe the outcome, not the activity
Start with what will exist or change when the task is complete. Reviewed drawings returned with comments resolved is clearer than work on drawings. A supplier selection documented with price, lead time, and approver is clearer than research suppliers. Outcomes let people inspect completion without guessing how much effort occurred.
Use verbs that point to a finished state: approved, installed, reconciled, tested, issued, or scheduled. Then name the object and relevant boundary. If the task covers only one floor, account, or reporting period, say so. Clear scope protects both the requester and the person completing the work.
Name the quality and evidence bar
Completion usually includes more than the main deliverable. Ask what evidence makes the result trustworthy: a checklist, signed approval, photo, test record, linked document, or written confirmation. Choose evidence that matches the risk rather than collecting attachments for their own sake.
Quality criteria should be observable. Accurate and professional are intentions; no unresolved comments, totals match the source ledger, and filename follows the project standard are checkable. If a standard or template already exists, link it instead of rewriting it inside every task.
Identify who accepts the result
A task may be complete for its owner but still need review. Name the reviewer or decision-maker and explain the expected response. If approval must happen before a deadline, include the review window so the plan accounts for it rather than treating approval as instant.
Clarify whether silence counts as acceptance; in most important work, it should not. Use an explicit status such as ready for review, approved, or changes requested. This keeps execution and acceptance separate and shows exactly where work is waiting.
Right-size the definition
A five-minute administrative task may need only one sentence. A client deliverable or safety-sensitive change deserves more detail. Apply the smallest definition that prevents a meaningful misunderstanding. Excessive criteria can hide the finish line inside process language and slow simple work.
When new information changes the finish line, update the task and notify affected people. Do not quietly add conditions after the work is delivered. A visible change preserves trust and lets the owner renegotiate time, priority, or support before doing extra work.
Write a four-part finish line
- Choose one upcoming task that involves another person or a meaningful risk.
- Write the observable outcome and the boundary of what is included.
- Add the quality check and evidence that will demonstrate completion.
- Name the person who accepts it and the review timing, then confirm agreement.
Common questions
Is a definition of done only for software or formal projects?
No. It helps with any work where people could interpret completion differently, from preparing a meeting package to closing a maintenance request. The definition can be a single clear sentence when the task is small.
What if the requester cannot define the exact result yet?
Define the next learning milestone instead. For example, complete when three options, key constraints, and a recommendation are ready for review. That creates an honest finish line without pretending the final answer is already known.
