Acceptance Criteria

The starting point is that "it's done" meant different things to different people. The side building it considered the work done once the screen loaded and the button responded. The side who asked for it considered the work done once the screen behaved the way they had pictured. That the two were looking at different pictures only surfaced on the day they opened the finished screen together.

Writing requirements as a single sentence each did not fix this. "As an admin, I want to put an expiry date on links I share with clients outside the company" says clearly why the work exists, and says nothing about where it ends. What someone opening an expired link should see, whether the date can be edited afterward — neither appears anywhere in the sentence. The developer filled those blanks with one judgment and the person who asked had filled them with another.

The bill for the blanks arrives all at once at review time. The moment someone opens a feature handed over as finished and says "this isn't supposed to work like that," the work stops being building and becomes fixing. Laying a condition onto a structure that already exists takes longer than it would have taken to build knowing about it.

Acceptance criteria move that check to before the build. The questions that would come up in review get written as sentences first, and development starts from a state where both sides agree on those sentences. The job is the same job review does, only earlier, and that gap in timing is the gap between the cost of fixing and the cost of building.

Each line says what happens in what situation when someone does what, written so that trying it sorts the line into true or false on the spot. Cutting a line into three pieces makes a missing piece visible.

1. Situation — the premise the condition applies under. Write it with the value in it, as in "a link with its expiry set to 7 days." Without a value, every person checking it opens it under different conditions.
2. Action — what the user does, as in "opened on the eighth day." Write what a person does, not what runs behind the screen.
3. Outcome — what becomes visible or changes as a result, as in "an expiry notice appears." Write what can be confirmed with your eyes.

Put the earlier example into that shape and lines like these come out.

• A link with its expiry set to 7 days, opened on the eighth day, shows an expiry notice.
• Someone opening an expired link sees neither the document title nor its contents.
• The expiry date can be edited after the link is created, and the new value applies immediately to links already sent out.

The lines that go missing most often describe what happens when things go wrong, not when they go right. What happens if the expiry date is set to yesterday, what happens to someone who had the document open right before it expired — edge cases belong here. They are rare but they need a decision, and an unwritten decision is one the developer makes alone.

Pinning down what is out of scope, in one line, cuts down on arguments later. Something like "reissuing an expired link is not part of this."

Three to seven lines is the common range.

The writer is the side that asked for the work. Usually a product manager drafts the list, but nobody finishes it alone. When the requester writes it by themselves, the constraints the building side knows about drop out. The sentences that end up in the list get made in the session where a developer and a tester read the draft line by line and ask "how would I check that."

Three groups read it.

1. The people building it, who use it to see how far the work goes. Anything not on the list is not part of this round, which makes the list a defense against scope quietly widening.
2. The people checking it. Quality assurance (QA), the function that verifies quality before release, copies the list straight into its checks. One line becomes one check.
3. The people who touch it later. Someone modifying this screen six months from now reads the list and learns what the screen was built to protect.

The timing is before development starts. Work with empty criteria cannot be sized, which makes it hard to pull into a sprint. Criteria added mid-build mean the work grew, so they either go into the plan or wait for the next item.

"That's not in the acceptance criteria, so it's out of scope. I'll split it into its own story."

Not a refusal of the request, a proposal to move it down the queue.

"This line just says 'loads quickly.' How many seconds do you mean?"

The sentence can't be sorted into true or false, so someone is asking for a number.

"All the acceptance criteria pass, but the shared checklist doesn't, so it can't go out this cycle."

The definition of done (DoD), the checklist the team applies identically to every item, still has steps like review or deployment outstanding.

At Pagedeck these sentences come up in the meeting where next cycle's work gets refined. Mia reads out the three criteria for the link expiry feature, and Theo asks, line by line, how he would verify each one. At "an expiry notice appears," Theo asked where that screen was, Noa said it didn't exist yet, and drawing it moved into the same piece of work on the spot. Had nobody read the criteria aloud, the missing screen would have turned up only after the build was finished.

The most common mistake is reading the list as a place to dictate how to build something. The more precisely the conditions are written, the less room there is to diverge, so it becomes tempting to write the implementation down too. But what goes in this list is the result confirmed from outside, not the mechanism running inside. Where the expiry state is stored is for the building side to decide; that an expired link shows no contents is what gets checked. Nail down the mechanism and a better mechanism becomes unusable because it violates the criteria, while a build that follows the mechanism and misses the result still reads as passing.

Treating more conditions as safer is the other one. After getting burned by an omission, people start writing down everything that comes to mind, and nobody reads a twenty-line list to the end. What the list needs are the lines that decide whether this work is finished, and that count rarely goes past seven. Going past it means the size of the work needs adjusting, and left alone it becomes work that doesn't fit in a cycle.