🔗 Acceptance criteria that actually work

Acceptance criteria, or AC, describe what a feature or bugfix does. Writing them is an art, and some AC work much better than others. So, how do we make them work? By including a little more detail.

Let’s explore the goals of AC, a standard example, an example that works better, a few counterarguments, and how to write great AC with ease.

Goals of AC: “Right Thing”, “Thing Right”, Documentation

What are the goals of AC? They should:

• Help us build the “right thing”
• Help us build the “thing right”
• Document the thing

Build the “right thing” and building “thing right” are the goals of all software writing. More about that in a minute.

For documentation, I want as many people as possible to understand my work. This includes new hires, engineers, designers, PMs, team leads, and could even include executives.

But mainly, I want engineers to understand the work later. Tickets can be a rich artifact about how and why something was done in the past. But only when we write them well.

This is why AC matters!