What Does \"Done\" Mean? Acceptance Criteria for a Software Project (Form)
Software projects usually end in a meeting room, not in code. The supplier says “we’ve delivered.” You say “not like this.” Both of you are right, because nobody ever wrote down what “done” meant.
I’ve spent years on both sides of that table, and I’ll say this plainly: the number of projects that stall on technical incapacity is small next to the number that stall on an undefined delivery.
The fix isn’t a methodology. It’s one form, filled in before the project starts and signed by both sides.
📄 Software project acceptance criteria form (free PDF)
Why acceptance criteria get skipped
Because everyone is optimistic at the start. Scope gets discussed, price gets discussed, timeline gets discussed — defining “done” feels like unnecessary formality. “We’ll work it out.”
You won’t. Six months later each side remembers its own finish line, and they aren’t the same one.
Writing the criteria costs an hour. Not writing them costs a negotiation at the end of the project that nobody wins.
The four parts of an acceptance criterion
A statement only counts as an acceptance criterion if it has all four. With three, it’s still arguable.
| Part | Example | Why it’s required |
|---|---|---|
| Which job | “A field engineer can close a work order from their phone” | Not a feature — a completed job |
| In which environment | “On a five-year-old Android handset, on site, with no signal” | What works in the office may not work in the field |
| A measurable condition | “Saves offline and syncs within 60 seconds of reconnecting” | “Make it fast” can’t be measured, only argued about |
| Who signs off | “Site supervisor” | If nobody is named, nobody signs |
🔴 The fourth is the most skipped and the most critical. If the person who will use the system — supervisor, foreman, field crew — isn’t among the people signing off, it works on paper and not in the field. What that costs is set out in nobody is using the software you paid for.
The difference between a “feature” and a “job”
The commonest mistake in writing criteria is listing features.
❌ “There’ll be a login, a work-order screen and a reports screen.” ✅ “In the morning the field engineer sees the day’s jobs on their phone, opens one, adds a photo, closes it, and the closed job appears in the office within 60 seconds.”
The first is a parts list; the second is a commitment to usability. Three screens being “built” doesn’t mean the job runs end to end, and what you’re buying as a customer isn’t screens, it’s a working job.
The rest of the form: four more sections
1 · Scope table. Three columns per item: this phase · phase two · out of scope. The third column is the valuable one — anything not written as out of scope turns into “but we were expecting that too” at delivery.
2 · Ownership. Five lines, none of them optional. IP transfers to you. Repos, servers, domain and store accounts in your name. Source code, database schema and a setup document at delivery. Data exportable on demand. A bug-fix period after delivery, and the rate afterwards.
These aren’t price items, they’re ownership items. Without them you end up with a working application you may not actually own.
3 · Stop criterion. By what date, and failing which result, do we stop this project?
That single line is the most skipped and the most money-saving one on the form. A criterion not written at the start never gets written: the project carries on under its own weight, because past a certain point nobody wants to bear the cost of saying “let’s stop.” Sunk cost takes the decision hostage.
4 · Pilot scope. Which single department, site or line goes first? Rolling out everywhere at once hides problems rather than fixing them — when everyone complains at the same time, you can’t tell which complaint is real.
Who writes the criteria
The supplier drafts the form and you approve it. They own the technical language, you own the knowledge of what the work actually is. That order breaks in two places, and both are expensive. Leaving it entirely to the supplier produces criteria written around what is deliverable rather than what is needed: lines like “the login screen works” get satisfied technically while the job still doesn’t run end to end. Writing it entirely in-house produces criteria nobody can measure (“it should be user-friendly”, “it should be fast”), so at handover each side defends its own reading.
The right arrangement sits in the middle and takes one meeting. You describe the job: “the field team can close a work order from a phone.” The supplier makes it measurable: “saves offline, syncs within 60 seconds of reconnecting.” And the person who will approve it is in the room. That person has to be the one who uses the system — a project that hands approval to a manager who never does the work takes the shortest possible route to software nobody uses in the field.
Three traps when writing criteria
“We’ll pin that down later.” The vague part of a scope never clarifies itself; it sits there until handover day, when both sides read it in their own favour. Anything that can’t be made specific goes into the form as not in this release. It does not stay ambiguous.
Making everything a criterion. A thirty-item acceptance list produces the same outcome as no list at all: nobody reads it, and the argument happens anyway. Five to eight items that carry the actual work beat thirty that don’t; the rest belongs in the scope section of the contract.
Using criteria as a pricing lever. Acceptance criteria are not a way to add work later. When something surfaces that isn’t in the form, the correct answer is not “let’s squeeze it into the criteria” but write it up and price it as additional work. A client who stretches criteria gets a higher quote next time — the supplier prices that risk in.
Progress rhythm: working software, not a report
The final section is three lines:
- A 15-minute demo every two weeks, with real data on a real screen. Nobody can verify a project that is “70% complete”; a demo can be verified, and it shows delay early.
- A fixed 30-minute weekly status call.
- One three-column list: to do / doing / done. You don’t need a tool; being regular matters more than the tool.
Together those three solve the thing owners actually suffer with: losing sight of the work. If “where is it, what’s done, what’s waiting” gets answered weekly, the project doesn’t produce large surprises.
Before this form and after it
- Before: buy a package or commission a build? The scorecard and the reasoning: off-the-shelf software or a custom build
- After: the system was delivered but isn’t being used: nobody is using the software you paid for
- Alongside: software is a business asset too — the business asset inventory
The most expensive uncertainty in a software project isn’t technical, it’s definitional. A business that spends an hour writing down what “done” means doesn’t sit down six months later to a negotiation nobody wins.
Fuat Çakır — industrial engineer and management consultant. He works on software project structure and supplier management in manufacturing and service businesses, and builds and ships his own mobile apps.
Frequently Asked Questions
How do you write acceptance criteria for a software project? A statement only counts if it has all four parts: which job (a completed job, not a feature), in which device and environment, under what measurable condition, and who signs it off. The fourth is the most skipped — if nobody is named as the approver, nobody approves.
Why does the scope table need an “out of scope” column? Because anything not written down becomes “but we were expecting that too” at delivery. Every item in the scope table should carry three columns: this phase, phase two, out of scope. The third is the most valuable and is usually left empty.
What is a stop criterion for? It answers, at the outset, “by what date and failing which result do we stop this project.” A criterion not written at the start never gets written. The project continues under its own weight because past a certain point nobody wants to bear the cost of stopping it.