How do you know when work is actually done?

Different definitions of done create hidden friction

A task can look complete to the person doing it and unfinished to the person depending on it. One person means a draft exists; another means it has been reviewed, approved, published, and handed off.

When a team leaves those expectations implicit, work appears to move while uncertainty accumulates around it.

Start with an Impact Hypothesis

An Impact Hypothesis connects the work to its intended result and the evidence that will count as success. It can be written in plain language: We believe doing X will contribute to Y, and we will know we succeeded when Z is true.

This shifts the conversation from whether a task was performed to whether the work produced the state the team needed.

• Name the action or artifact being created.
• Name the outcome it is expected to influence.
• List the observable success requirements.
• Identify who confirms that those requirements are met.

Break the work down without losing the outcome

A work breakdown makes the steps visible and assignable. The useful level of detail is enough for another person to understand what remains, who owns it, and what dependency can block it.

The breakdown supports the hypothesis; it does not replace it. A team can complete every listed action and still miss the outcome if the success requirements were weak.

Use stages and states to show reality

Stages such as To Do, Doing, Review, and Done reveal where work is in its journey. States such as Ready, Active, Blocked, and Complete add operating context.

Together, they make it easier to distinguish unfinished work from waiting work, overloaded work, and work that needs a decision.

Let the definition improve

A definition of done is a working agreement, not a permanent law. When a project reveals a missing review, handoff, or quality requirement, update the system so the next piece of work carries that learning forward.