Define “Done” Before You Start

Define “done” before implementation. A useful definition names the scope, expected behavior, tests, documentation, and submission or deployment evidence. It turns “work on the project” into claims that can be checked.

Separate outcome from activity

“Spend three hours coding” is an activity. “Given a valid CSV file, produce a summary containing row count and the mean of the score column” is an outcome.

Start with:

The project is done when [reader or user] can [observable outcome] under
[conditions], and the result is verified by [evidence].

Do not write criteria after seeing what the current implementation happens to do. That turns the checklist into a description, not a target.

Bound the scope

List included behavior and explicit non-goals:

Included:
- Read one local UTF-8 CSV file.
- Validate a required numeric score column.
- Print count and mean.

Not included:
- Graphical interface.
- Cloud upload.
- Automatic repair of malformed data.

Non-goals protect time and make later ideas visible without silently expanding the assignment. Course requirements override your preferred scope.

State expected behavior

Specify inputs, outputs, and important conditions:

• valid input and expected result;
• boundary values such as an empty valid dataset;
• invalid input and expected failure;
• units, rounding, ordering, and file locations; and
• behavior that must not occur.

Avoid “works correctly.” Name what a person can observe.

Connect tests to criteria

For each behavior, record a check:

Tests are evidence for defined behavior, not decoration added after coding. Identify manual checks when automation is not practical.

Include documentation

Done may require:

• a README with requirements, installation, running, and testing;
• comments for non-obvious decisions;
• attribution and license information;
• a sample input with no private data; and
• known limitations.

Documentation must agree with actual commands and tested versions.

Define delivery evidence

Submission and deployment are separate from local success. Record:

• required filename and format;
• authorized destination;
• deadline and time zone;
• files that must and must not be included;
• successful upload, build, or deployment evidence; and
• receipt, URL, commit, or version identifier when provided.

Do not place credentials, student records, private feedback, or restricted data in screenshots, repositories, logs, or sample inputs.

Use a definition-of-done template

# Definition of Done

## User and outcome
## Included scope
## Non-goals
## Expected behavior
## Expected, boundary, and invalid tests
## Documentation
## Privacy and safety
## Submission or deployment
## Evidence to retain
## Unresolved decisions

Verify the definition itself

Ask another person to read it without your explanation. Can they decide whether the project is done? Mark vague words, missing conditions, and checks that cannot actually be run.

Revise when requirements legitimately change. Record why; do not quietly lower a criterion because implementation is difficult.

Common mistakes

• Defining done as effort or feature count.
• Omitting invalid behavior.
• Adding unrequested features.
• Treating local execution as confirmed submission.
• Claiming tests before running them.
• Using invented screenshots or results as portfolio evidence.

Do this now

Complete the template for a small existing or fictional project. Create one known input and expected output, then run a criterion that could fail.

If the definition-of-done template feels like a large writing task, use the one-question-at-a-time chatbot workflow to collect the criteria. You still decide the scope and acceptance conditions.

Log what you learned

The definition-of-done record is the learning log. Add observed evidence only after running the named check, then save any unresolved requirement. Next, use a reproducible scientific process when observed behavior differs from this definition.