Acceptance criteria are the specific conditions that have to be true for a feature to be accepted as complete and working. They are the criteria a developer, or in some cases a designer, has to meet for you to accept the work.

You write them, not the person building it. That is the product side of the job, and it is where "it's done" either starts meaning the same thing to both of you or quietly stops.

The one rule that matters

Every item in the list must be checkable yes or no. Either yes, it does this thing, or no.

It is never like, oh, it does this thing when it does this. If an item needs a conversation to determine whether it passed, it is not an acceptance criterion yet, it is a feeling about the feature.

You can consider these test cases, and they can map directly to writing tests. That is a useful check on your own writing: if a developer could not turn the line into an automated test, sharpen it.

Where they live

When you are detailing a feature, you write the problem statement or a user story, and then a list of acceptance criteria underneath it.

Every feature needs a problem statement explaining why it exists, and under each one you list everything that has to be true for it to be complete. The problem statement is why you are building it and the criteria are what it means for it to exist. Written together, they stop the feature drifting from its reason while it is being built.

Describe the behaviour, not the appearance

You are saying what will be built. Not how it will be built, and not what it looks like.

"The user can see the total for the week without leaving the daily view" is an acceptance criterion. "Use a cached aggregate query" is an implementation decision and it is not yours to make here. "The total sits in a grey box on the right" is a design decision, and that is not yours either. My acceptance criteria are not a source of truth for design. They are a source of truth for functionality and behaviour.

One habit worth copying: always follow through to the resulting state. Not "the user can tap Save", but what is true once they have.

Do not let the list become a log

Most product managers do not like using check boxes in a ticket for acceptance criteria.

The reason is that when a developer ticks them off, they are in essence modifying the description. It is not a source of truth any more. Instead of being a source of truth it becomes a log of work done.

Keep the criteria as the fixed statement of what done means, and track progress somewhere else.

If you are building it yourself

You still write them, and it takes about five minutes a feature.

They are what stop the definition of done from moving while you are tired. You decided in advance what this feature has to do. When you are four hours in and want to be finished, the list is the thing that argues back.

The order to work in

Define your problem, your goals, your requirements and your acceptance criteria, and then think about implementation.

If you are working alone, the problem statement is the piece I would tell you not to skip. Acceptance criteria come next, and they matter most the moment another person is involved in building anything.

Keep reading

What Is a PRD and Do I Need One If I'm Building Alone?

What Do I Need to Know Before Hiring a Developer?

What Happens When You Hire a Developer Without a Strategy

Learn this with me

Acceptance criteria are class 8 of From Passion to Product, my free six-week live course, taught with the PRD and followed straight away by quality assurance and how to write a bug report. You write criteria for one of your own features in the class, and I go through good ones against the common mistakes.

I teach the same material to engineering teams, as a one day workshop or a longer program, because this is usually where a team's disagreements actually live.

Join the waitlist for the free cohort, get the workbook, or look at the team programs.