Should I Buy It?
A task without a completion criterion stays open in your brain. It resurfaces, consumes attention, generates a diffuse residual stress. Explicitly defining when a task is “done” — before starting — radically changes execution quality and the sense of progress.
Origin
The Definition of Done emerged in agile software development, formalized by Ken Schwaber and Jeff Sutherland with the Scrum framework in the 1990s. The principle: a User Story is only “done” when an objective checklist is fully satisfied (code written, tested, reviewed, deployed, documented). No grey zone, no “pretty much finished.”
The concept extends far beyond software — it applies to any task where the boundary between “done” and “not done” is fuzzy.
The Theory
The problem of psychological openness
David Allen, in Getting Things Done (2001), calls this phenomenon “open loops”: any task without a clear endpoint stays active in the brain, consuming working memory and generating anxiety. The Definition of Done closes the loop in advance.
Precision as the condition for completion
“Deal with laundry” stays open. “Start the washing machine” closes. “Finish the report” stays open. “Export the report as PDF and email it to Marie” closes. The difference isn’t in difficulty — it’s in the precision of the terminal criterion.
When you define matters
Defining the completion condition at task creation, not at execution, changes everything. At execution, you’re often in focus mode — stepping back to ask “what does done even mean here?” costs concentration. This reflection is better done in cold blood.
In Practice
Some concrete reformulations:
| Vague task | Definition of Done |
|---|---|
| ”Do the accounting" | "All March invoices entered in the tool, monthly report exported" |
| "Prepare the meeting" | "Agenda sent to attendees, slides finalized, room booked" |
| "Work on the project" | "Section 2 of the brief drafted, proofread, and saved as draft” |
In the Todo Manager, each task created via the Telegram bot automatically includes a “Validation Criterion” field. The system explicitly asks: “How will you know it’s done?” If the answer is vague, the system prompts again. The definition happens at creation — not at execution.
Nuances and Limits
The Definition of Done can become counterproductive if too rigid in creative or exploratory contexts. Some tasks legitimately end when you “decide to stop” rather than when an objective criterion is met (brainstorming, code exploration, rapid prototyping).
A useful distinction: criterion-based tasks (reply to an email, deploy a feature) vs timeboxed tasks (think about a strategy for 45 minutes). For the latter, the Definition of Done is the duration, not the output.
Sources: Schwaber & Sutherland, The Scrum Guide (2020) · Allen, D. (2001). Getting Things Done. Viking