An action item needs a definition of done

An action item is ready to assign when everyone can answer one question the same way: what will we be able to see when this is done?

Record the result, the evidence that proves it, any required reviewer and the limits that keep the work from expanding. Then give it an owner and a date.

Without that completion test, “prepare the launch brief” can mean a rough outline to one person, an approved document to another and a customer-ready plan to a third. The owner can work responsibly and still disappoint the room.

Write the result, not the activity

Many action items describe motion:

• look into the onboarding problem;
• review the contract;
• work on the support plan;
• follow up with the client.

These verbs say what someone will spend time doing. They do not say what the work must produce.

Turn the activity into an observable result:

Activity: Review the onboarding drop-off.

Result: Add a one-page diagnosis of the three largest onboarding drop-off points, with the source data and one recommended next test.

The result does not need to be a file. It may be a decision, an approval, a repaired workflow, a confirmed answer or a conversation whose outcome is recorded. What matters is that another person can inspect it without guessing how much effort occurred.

Name the evidence that closes the task

A useful finish line tells the owner what to return to the record.

Choose evidence that matches the promise:

• a document attached at a named location;
• a link to the tested change;
• an approval or list of blocking changes from a named reviewer;
• a number with its source and measurement window;
• a decision recorded with its reasoning;
• confirmation that access works for the person who needs it.

“Message sent” proves an attempt, not an outcome. “Draft uploaded” proves a file exists, not that the required reviewer can use it. “Discussed with Legal” proves a conversation happened, not what Legal concluded.

For the onboarding diagnosis, the closeout might read:

Mira attaches the one-page diagnosis to the source meeting. Leon confirms that it contains the three drop-off points, source links and a recommended test. Approval of the test itself is a separate decision.

This keeps completion honest without quietly adding work. The task is to produce a usable diagnosis, not to win approval for every recommendation inside it.

Separate the owner from the reviewer

The owner creates the result. The reviewer answers whether it meets the agreed test.

Those roles should be explicit when the work affects another team, requires specialist judgment or carries material risk. A security reviewer may need to approve a control. A client sponsor may need to accept a revised scope. An engineering lead may need to confirm that a handoff contains enough detail to schedule.

Do not make “the team” the reviewer. Name one person who can return one of three clear answers:

1. accepted;
2. accepted with named follow-up that does not block use;
3. not accepted, with the unmet part of the original test identified.

The reviewer should not invent a new finish line after the owner delivers. If new information genuinely changes the requirement, record that as a scope change and make a new agreement about the date.

Put boundaries around the promise

A definition of done should prevent scope creep as well as ambiguity.

Name the most important exclusions:

The diagnosis covers new self-serve accounts from the last 30 days. It does not redesign onboarding or analyse enterprise implementations.

That sentence protects the owner from an infinite interpretation of “look into onboarding.” It also tells the room what a later task may still need to address.

Useful boundaries often describe:

• which audience, market or account group is included;
• which period the evidence covers;
• whether the deliverable is a draft, recommendation or approved final;
• which systems or workflows are out of scope;
• how much uncertainty is acceptable;
• which downstream decision is not part of this task.

Do not list every conceivable exclusion. Capture the one or two misunderstandings most likely to change the effort or the usefulness of the result.

Match the test to the risk

Not every action item needs a mini specification.

“Book the project room for Tuesday” has an obvious result: the booking exists and attendees can find it. Adding five acceptance criteria would make the record harder to use.

Add a fuller definition of done when:

• the verb is broad, such as review, investigate, prepare or improve;
• the work crosses teams;
• a reviewer or approval is required;
• the result will trigger spending, release or customer communication;
• similar work has previously bounced back as incomplete;
• the owner was not present when the task was created.

For simple work, one sharpened sentence is enough. For consequential work, use a compact result-evidence-reviewer-boundary format. The goal is shared understanding, not paperwork.

This discipline complements an owner and a date. Ownership answers who will move the work. A due date answers when the result is expected. A definition of done answers what promise those two fields refer to.

Do not confuse “done” with “successful”

A completed action item can produce an unwelcome answer.

Suppose the team asks Priya to test whether a supplier can meet the launch quantity. Her task may be done when she returns a documented capacity answer by Friday. If the answer is “no,” the task still produced the agreed result. The launch plan now needs a decision, but Priya's investigation should not stay open merely because the evidence disappointed the team.

Separate three states:

• done: the promised result and evidence exist;
• accepted: the named reviewer confirms they meet the agreed test;
• successful outcome: the evidence supports the team's preferred path.

Collapsing these states encourages people to hide bad news or keep completed investigations open. A meeting record should make an adverse result easier to act on, not harder to report.

Close the action item with a short receipt

When the work is complete, leave a closeout note that points to the evidence and any new consequence:

Completed: Onboarding drop-off diagnosis attached.

Evidence: Three priority drop-off points, source queries and one recommended test are included.

Reviewed by: Leon, accepted 18 September.

Next decision: Choose whether to run the recommended test; not part of this action item.

This receipt prevents a future reader from reconstructing completion from scattered comments. It also stops the original task from absorbing every next step created by its result.

In Scripta, action items can carry an assignee, due date, priority, status and source meeting. Teams can keep the supporting files, comments and decisions with that meeting record. Scripta does not decide that a vague task is complete for you; write the finish line into the action itself and use the connected record to show the evidence.

If the task later changes hands, preserve the finish line in the action-item handover. A new owner should not inherit a different definition under the same title.

Use this four-line definition of done

Before the meeting closes, write:

Result: [the observable output or answer].

Evidence: [what will be attached, linked or recorded].

Reviewer: [who confirms the agreed test, if needed].

Boundary: [the important scope limit or exclusion].

Then add the owner and date, and ask the owner to read the finish line back in their own words.

An action item should not require a debate at the moment someone marks it complete. Define the evidence while the people who need the result are still in the room.