Most disputes about software milestones come from one sentence: “it should work properly”. Clear acceptance criteria turn that into checks anyone can run. These four steps write them before work starts, test them during delivery and use them to close the milestone.

Step 1 — Start from the outcome

Goal: Tie every criterion to what the milestone is for.

  1. Write the outcome in one sentence: who can do what, that they could not before.
  2. List the main tasks a user must complete for the outcome to be true.
  3. Name the systems and data each task depends on.
  4. Agree who will sign the milestone off.

You finish with: An outcome statement and a list of user tasks.

Step 2 — Write testable criteria

Goal: Turn each task into checks with a clear pass or fail.

  1. For each task, write: given a starting situation, when the user does something, then this result appears.
  2. Include the important failure cases, such as missing data or wrong permissions.
  3. Add basics that are easy to forget: access control, error messages, performance on real data volumes.
  4. Remove anything that cannot be checked.

You finish with: A numbered list of testable acceptance criteria.

Step 3 — Test during delivery

Goal: Find gaps early instead of at the deadline.

  1. Review the criteria with the delivery team before work starts.
  2. Demo against the criteria at each checkpoint, not only at the end.
  3. Record which criteria pass, fail or have changed, and why.
  4. Agree any change to the criteria in writing, with its effect on time and cost.

You finish with: A running pass and fail record with agreed changes.

Step 4 — Accept and hand over

Goal: Close the milestone cleanly.

  1. Run every criterion on the final version with the person who signs off.
  2. List open issues and agree which are fixed now and which wait.
  3. Confirm documentation, access and ownership are handed over.
  4. Sign off in writing and set the next milestone, if any.

You finish with: A signed acceptance record and handover.

Common pitfalls

  • Criteria like “works well” that cannot be tested.
  • Writing criteria after the work is done.
  • Only testing the happy path.
  • Changing scope without updating the criteria.

See it as a workflow

Leadership

Rescuing a stalled software build

Take a product build that is over time and over budget, find out what is really done, and reset it to a fixed-scope milestone the team can actually deliver.

See the workflow

More guides like this

Related answers

Read as Markdown Milestone & Custom Delivery