How to Define Done for a Small Project: A Proof Checklist

Done is not the moment a task list looks quiet. It is the moment the promised change exists, the quality bar is met, the result is in the hands of the person who needs it, and the evidence is easy to find. For a small project, a definition of done is a short agreement that keeps “almost finished” from becoming a second project.

In Scrum, the Definition of Done is a shared set of criteria for deciding when an increment is complete. Acceptance criteria answer a narrower question about one item: did this requirement happen? You can use the distinction outside software without importing a heavy ceremony. The point is simple: make the finish line specific enough that two reasonable people would reach the same call.

What is a definition of done for a small project?

A definition of done for a small project is a short, testable description of the conditions that must be true before you close the work. It should describe the result, not the effort. “Spent three afternoons on the landing page” is effort. “A visitor can understand the offer, submit the form, and receive the stated next step” is a result.

That difference matters because small projects often hide their unfinished work. The main task may be complete while the handoff is unclear, the final file is difficult to locate, or one important path has never been checked. A useful definition of done protects five things:

• The promised change: the project did the job it was opened to do.
• Usability: the intended person can use or receive the result.
• Quality: the agreed checks are complete at the right level for the work.
• Handoff: ownership, location, instructions, or next access are clear.
• Evidence: someone can see what was checked and what remains outside the scope.

You do not need a long checklist. You need a visible boundary.

The four parts of a durable finish line

1. Name the outcome in plain language

Start with the change, not the artifact. An artifact is what you make. An outcome is what becomes possible because you made it.

Instead of “finish the presentation,” write “the decision-maker can compare the three options, understand the recommendation, and approve the next step.” Instead of “launch the resource,” write “the intended reader can reach the resource, understand its purpose, and find the next action.” The examples are not promises of a specific result. They are ways to force the finish line into observable language.

Keep the outcome narrow. If the sentence contains several unrelated changes, you may have combined multiple projects. Split them, or use the capacity rule from the Journal’s guide to working on multiple projects before you add more work to the finish line.

2. Set the minimum quality bar

Quality is not “make it perfect.” Quality is the set of checks that prevents the finished thing from creating an avoidable problem for the next person.

Choose the few checks that matter for this project. A small public page might need a working primary path, readable copy, accurate links, and a review on the device most people will use. A research brief might need source links, a clear date, a stated limitation, and a conclusion that follows from the evidence. A physical deliverable might need a fit, safety, or operating check appropriate to its use.

Write these checks before the last hour. Otherwise, the quality bar tends to expand whenever you feel uncertain. That is not rigor. It is an unpriced change to the project.

3. Make the handoff explicit

A project is not complete merely because the maker is finished looking at it. The result has to move to its next context.

Specify who receives it, where the final version lives, what they need to know, and what they are expected to do next. If you are the only person involved, future-you is still a recipient. Put the final file in the location you will actually find, label the version, and leave one sentence explaining the next use.

If the project depends on an unverified condition, record it instead of quietly passing it forward. A concise project assumption log can keep an open question visible without pretending it is resolved.

4. Attach proof to the decision

Proof does not need to be dramatic. It can be a link to the final page, a reviewed file, a test note, a sign-off message, a before-and-after comparison, or a short record of what was checked. The form should match the risk and the audience.

The useful question is not “can I defend how hard I worked?” It is “what would let the next person trust that this is complete enough for its intended use?” If the answer is hard to locate, the work may be finished in your head but not finished in the system around it.

Definition of done vs. acceptance criteria

These terms belong together, but they do different jobs. Acceptance criteria describe the specific conditions a feature, deliverable, or request must meet. A definition of done describes the broader completion standard that applies to the work as a whole. Acceptance criteria can pass while the work still lacks documentation, review, handoff, or evidence.

For a small project, keep both lists short. Acceptance criteria keep the promise honest. The definition of done keeps the finish line from stopping at the first visible artifact. Scrum.org’s definition of done reference is useful if you are working with a Scrum team and need the formal context.

How to write the checklist before the project starts

1. Write one finish sentence. Describe the change a user, client, teammate, or future-you should be able to see.
2. List three to seven gates. Include the outcome, the important quality checks, the handoff, and the proof. If you need twenty-five gates, look for a hidden project or a missing decision.
3. Name the evidence. Decide what will show each gate is true. “Reviewed” is weak unless you can say what was reviewed and by whom.
4. Name the closer. Decide who can accept the result or make the call that it is complete. The whole team can contribute without making closure ownerless.
5. Park new requests. When a new idea appears, ask whether it changes the promised outcome or improves the agreed result. If it changes the outcome, open a new decision rather than quietly moving the finish line.

Use the same checklist during the project, not only at the end. If one gate is impossible to satisfy, you have found a scope, dependency, or quality decision while there is still time to act.

A definition-of-done template you can use

Copy this into the project brief, task, or working note:

• Project: What are we completing?
• Outcome: What change should exist when it is complete?
• Acceptance criteria: What must the result do or contain?
• Quality gates: What must be checked before handoff?
• Handoff: Who receives it, where does it live, and what happens next?
• Evidence: What link, file, note, review, or test proves each gate?
• Out of scope: What is deliberately not part of this finish line?
• Close: Who makes the final call, and on what date?

When the project reaches the end, read the template as a decision record. Mark each gate pass, record the evidence, and name any accepted limitation. If a material gate fails, the honest choices are to fix it, reduce the promise, or leave the work open. “Ninety percent done” is not a useful status unless the remaining ten percent is named.

The uniform is part of the rhythm, not the proof. For a colder work block or the walk between obligations, the live Heavyweight Hoodie is a relaxed, heavyweight fleece layer with a soft lined hood, ribbed cuffs and waistband, and a 10 oz/yd² cotton/polyester fleece blend. Choose it for that use case, not as a reward or a promise that the work will get easier.

Define done early. Check it without drama. Close the work with enough evidence that the next step can begin cleanly. Then return to The Self Made Journal for the next useful question.