Software Milestone Acceptance: 7 Tests Before Sign-Off

Use seven software milestone acceptance tests for scope, working evidence, real workflows, quality, release readiness, ownership, and written sign-off.

Aug 20, 2026

Software Development

Use seven tests before accepting a software milestone: agreed outcome, working evidence, realistic workflow, quality controls, release readiness, ownership, and a written disposition.

A milestone is not accepted because a team showed progress or closed a set of tasks. It is accepted when the buyer can inspect the agreed result, repeat the important workflow, understand the remaining risk, and take the next decision without relying on a presentation.

This checklist is for founders, product owners, and operations leaders reviewing an active software build. It applies to a design milestone, working feature, integration, migration, or release candidate. It does not replace the contract. It turns the contract and milestone brief into evidence that a non-technical buyer can inspect with a technical partner.

If the project has not started, first use the software scoping guide to define the business outcome, users, workflows, integrations, and constraints. Milestone acceptance works only when both sides agreed what the milestone was meant to prove.

What milestone acceptance should prove

Acceptance criteria describe what a feature or deliverable must do. A team definition of done describes the shared quality bar for completed work. User acceptance testing checks whether intended users can complete real business scenarios. A sound milestone decision uses all three where relevant, but it asks a broader buyer question: is there enough evidence to release payment, proceed, correct the work, or change the next scope?

The Scrum Guide says stakeholders inspect results and adjust for the next Sprint, while each Sprint should produce a usable Increment that meets the Definition of Done. That gives a useful baseline: inspect something usable, not activity, then change the plan from what the evidence shows.

Test	Question for the buyer	Minimum evidence
1. Outcome and scope	Did the delivered result match the agreed milestone?	Scope reference, acceptance criteria, exclusions, and a trace from criteria to evidence
2. Working evidence	Can the result be used outside a presentation?	Accessible environment, build or prototype, version, and repeatable demonstration
3. Real workflow	Does the important journey work with realistic roles and data?	Scenario results, role coverage, exception paths, and integration outcomes
4. Quality controls	What failed, what passed, and what risk remains?	Test results, defect record, security checks, accessibility checks, and known limitations
5. Release readiness	Can the team deploy, observe, and recover this increment?	Release steps, configuration, monitoring, backup or rollback path, and owner
6. Ownership	Can the buyer access and continue the work?	Repository, environment, account, documentation, and decision-log access
7. Disposition	Is the result accepted, conditionally accepted, or rejected?	Named decision, open conditions, owner, due date, and next-scope effect

The seven software milestone acceptance tests

1. The delivered outcome matches the agreed milestone

Start with the milestone statement, not the task board. Name the user or operator, the outcome they should reach, the included workflow, the excluded work, and the evidence promised for review. Then map each acceptance criterion to a screen, scenario, test result, document, or working system state.

A criterion such as "integration completed" is too vague. A testable criterion names the system, action, expected state, failure behaviour, and evidence. For example: when an approved customer record is created, the integration writes the external identifier back to the source system; a rejected record remains unchanged and appears in an exception queue.

If the work shown belongs to a future milestone, record it separately. Extra work does not compensate for a missing agreed outcome. The proposal comparison framework can help when scope differences began before the contract was signed.

2. Working evidence exists beyond a presentation

Ask to use the delivered artifact in an environment you can access. For a design milestone, open the source design file and follow the clickable flow. For a coded milestone, use the build tied to a named version or commit. For an integration, run the agreed transaction and inspect both systems. For a migration, compare source and destination records using the agreed reconciliation method.

A video, slide deck, or guided demonstration may explain the work, but it should not be the only evidence when the milestone promises working software. Record the environment, version, test account, data set, and date so the same result can be checked again.

3. The business workflow passes with realistic roles and data

Test the core journey from trigger to business outcome. Use representative roles, realistic data shapes, and at least one exception. A manager approval flow should cover the requester, approver, rejected state, notification, audit history, and what happens when the approver is unavailable. A customer portal should cover identity, permissions, failed submission, duplicate action, and support handoff where those risks are in scope.

Do not accept a happy path if the value depends on handoffs or exceptions. The buyer should know which scenarios passed, which failed, which were not tested, and why the remaining gap does or does not block the milestone.

4. Quality, security, and accessibility evidence is inspectable

Ask for the quality evidence agreed for this increment: automated and manual test results, supported devices or browsers, performance checks where relevant, defect severity, security verification, accessibility checks, and any accepted limitations. The evidence should show the tested version and the result, not only a statement that testing occurred.

OWASP ASVS provides a basis for testing web application security controls and for specifying verification requirements in contracts. NIST SSDF recommends integrating secure software practices into the development life cycle rather than treating security as a final review. For user-facing web interfaces, WCAG 2.2 provides testable accessibility success criteria. Choose the controls that match the product and milestone risk instead of claiming that every standard applies in full.

Separate defects from new requests. A defect means the delivered result does not meet an agreed criterion. A change request adds or alters scope. Record both, but do not turn a missing requirement into a defect or a failed criterion into paid new scope.

5. The release and rollback path is ready

A milestone may be acceptable without a production release if the agreed purpose was learning or controlled testing. The evidence still needs a clear operating boundary. State where the increment runs, who can access it, what data it may use, and whether it can affect customers or business records.

For a release milestone, inspect the deployment steps, configuration, monitoring, backup or rollback method, and named release owner. Ask the team to explain how it will detect a failed release and restore service. If recovery has not been exercised, label that fact rather than assuming the written steps work.

The software maintenance budget guide explains why monitoring, incident response, dependency work, and operating ownership should be visible before launch rather than discovered after it.

6. Code, environments, credentials, and documentation are accessible

Acceptance should not create a new dependency on one person or supplier. Confirm the buyer has the level of access promised for the milestone: source repository, build pipeline, test environment, design source, cloud or hosting account, third-party services, configuration records, and relevant documentation. Shared credentials should be replaced with named access where practical.

The agency handover checklist covers the deeper exit test when ownership moves to another team. During an active build, use the same principle in smaller form: the buyer should be able to inspect what has been funded and preserve the work if circumstances change.

7. The decision is accept, accept with conditions, or reject

End the review with one written disposition. Accept when the agreed outcome and required evidence pass. Accept with conditions when a limited gap does not block the milestone, but record the condition, owner, due date, and effect on payment or the next milestone. Reject when a required outcome or control is absent, not repeatable, or materially different from the agreement.

Do not leave important issues in meeting notes without a decision. The acceptance record should state what was reviewed, what passed, what remains open, who decided, and what happens next. The AI software statement of work template shows how deliverables and criteria can be defined before work begins; the record below closes that loop after delivery.

Map the first build milestone.

A copyable milestone acceptance record

Copy this structure into the project system or review document. Keep links to the evidence rather than pasting untraceable screenshots into a chat thread.

Field	What to record
Milestone	Name, purpose, review date, delivered version, and environment
Agreed outcome	User or operator, workflow, expected result, exclusions, and acceptance criteria
Evidence reviewed	Working artifact, scenario results, test reports, defect record, release evidence, access, and documentation
Open items	Defect or change request, severity, owner, due date, and whether it blocks acceptance
Disposition	Accept, accept with conditions, or reject
Next effect	Payment state, next milestone change, release decision, or required correction
Decision owners	Business owner, technical specialist where available, delivery owner, and decision date

A non-technical buyer does not need to perform every engineering test. The buyer does need to know which evidence was required, who reviewed it, what the result means, and which risk the business is accepting. Bring in an independent technical specialist when the milestone affects security, regulated data, a high-risk migration, or a release that the buyer cannot evaluate responsibly.

How the checklist changes by milestone type

Milestone type	Evidence that matters most
Discovery or design	User problem, tested journey, source files, decisions, constraints, and unresolved technical risk
Working feature	Acceptance criteria, real roles and states, test evidence, version, defect record, and integration behaviour
Integration	Source and destination state, authentication, retries, duplicates, exception handling, reconciliation, and audit trace
Migration	Inventory, mapping, validation sample, rejected records, reconciliation totals, rollback, and source preservation
Release candidate	Regression evidence, security and accessibility scope, deployment, monitoring, rollback, support owner, and known limitations

GOV.UK advises teams in an alpha phase to do the minimum needed to test the riskiest assumptions. Apply the same discipline to milestone acceptance: require evidence for the question this milestone was funded to answer, then resist turning every review into a full product audit.

What not to accept as proof

Do not accept task completion percentages without a working result. Do not accept a guided demonstration when access to the artifact was promised. Do not accept "tested" without the tested version, scope, and outcome. Do not accept source code without build and environment access when those were included. Do not accept a defect list without severity and disposition. Do not accept verbal agreement when payment, release, or the next scope depends on the decision.

The purpose is not to make every milestone adversarial. Clear evidence protects both buyer and delivery team. It prevents subjective rejection, exposes scope changes early, and gives the next milestone a reliable starting point.

How KUMO approaches milestone sign-off

KUMO works with founders and operators on product design and software delivery through inspectable milestones, weekly progress calls, and sign-off at every sprint. The founders partnership explains how KUMO helps shape, build, and operate a product when the business needs a senior delivery partner.

The Flickd case study is one example of KUMO product design and engineering work moving into a real product. Treat it as evidence of delivery practice, not as a promise that another product will have the same scope or path.

If your next milestone is difficult to define or accept, map the first build milestone.

Frequently asked questions

Who should accept a software milestone?

The business owner should accept the outcome, with a technical specialist checking engineering evidence where the buyer cannot do so responsibly. The delivery lead should supply the evidence and explain open risk. One named decision owner prevents a group review from ending without a disposition.

Is a sprint review the same as milestone acceptance?

No. A sprint review is a working session to inspect progress and adapt the backlog. A commercial milestone may span one or more sprints and can affect payment, release, or scope. Use sprint evidence inside the milestone review, but record the commercial disposition separately.

Should payment wait until every defect is fixed?

Not necessarily. The agreement should define which defects block acceptance. A low-risk issue can be accepted with a written condition, owner, and due date. A failed core workflow, missing security control, inaccessible deliverable, or absent release evidence may justify rejection when it breaches an agreed criterion.

What is the difference between a defect and a change request?

A defect means the delivered result does not meet an agreed requirement or acceptance criterion. A change request adds, removes, or alters the agreed scope. Classify the item before discussing effort or payment so both sides solve the same problem.

Can a non-technical founder accept a software milestone?

Yes, for business outcomes and observable workflows. The founder should ask for traceable evidence and use an independent technical specialist for security, architecture, migration, release, or ownership risks they cannot assess. Acceptance is a business decision informed by technical evidence, not a coding exam.