A milestone should describe a capability someone can verify
“Backend complete” is difficult for a business owner to accept. “An authorized operator can approve a request and see an auditable status history” names an outcome. Specify the starting conditions, action and expected result. Include failure and permission cases where they matter. Implementation tasks still belong in the delivery plan, but completion of a task does not automatically establish acceptance of the product behavior.
A fictional invoice example
A milestone might require an invoice draft to be created once after an approved order. Acceptance checks include a duplicate event, a missing billing address and a user without approval rights. The evidence can be a demonstration on agreed test data plus relevant automated checks. Do not use production personal data simply to make the demonstration appear realistic.
Keep scope changes visible
Separate a defect against an agreed criterion from a request for additional behavior. When learning changes the intended workflow, update the criterion and discuss the effect on scope and timing before implementation. Avoid a checklist so detailed that it prescribes every technical choice, but avoid vague adjectives such as “fast” or “easy” without a scenario or measurement method.
Make the invoice result inspectable
Turn the invoice example into a small acceptance record. Give the order a test identifier, an approved version, a billing address and a named role allowed to approve it. Write the expected invoice status and reference before running the scenario. The reviewer should find the resulting draft and its link to the approved order, rather than infer success from a notification or a developer’s explanation.
Repeat the same event and check that it points to the existing draft. Then remove the billing address from a separate example. Agree whether the order remains approved while invoicing waits for correction, and who can make that correction. This prevents the demonstration from treating a technical error message as a complete exception workflow. Test the correction through to the final draft as well.
Keep each observation with the application version, test conditions and relevant result. A short recording can help, but it should not replace an inspectable record. If a provider’s test environment cannot demonstrate an important behavior, state the gap and identify the evidence still needed. A local demonstration does not establish how an untested external dependency behaves.
Close the review with explicit decisions
During review, classify each disputed result against the agreed criterion. An invoice linked to the wrong order is a defect. A newly requested discount policy may change the scope. An unclear original rule needs a recorded decision before either party can judge the behavior. Keep these cases separate so that correcting an error does not quietly become a negotiation over unrelated features.
For every open item, record the owner, next action and evidence that will close it. If partial acceptance is useful, identify the accepted capability and the restriction that remains; an unresolved billing exception may still prevent release. Agree which affected scenarios must be repeated after correction. Replaying only the repaired screen can miss damage to the approved-order path or duplicate handling.
Finish with a decision log both sides can read: accepted, rejected or awaiting evidence, with reasons and the version reviewed. Separate that decision from permission to release to production, operational handover and any commercial milestone unless the agreement explicitly joins them. Clear boundaries let the team recognize completed work while keeping unfinished responsibilities visible.
Agree the review mechanics
Orvun Labs can help turn a product brief into milestones that a nontechnical owner can review. Identify the reviewer, environment, evidence and response window. Record unresolved items and the treatment of partial acceptance; silence should not hide disagreement.
- Who is authorized to accept the milestone?
- Which business, failure and permission scenarios must pass?
- What data and environment will be used for the review?
- How are rejected items, scope changes and final handover handled?
