Some simple guidance for writing good acceptance criteria

Introduction

I’ve previously written about the benefits of writing good acceptance criteria, and how it helps create the conditions for teams of engineers to self-organise. I’ve noticed that sometimes good acceptance criteria can be elusive, and that writing them well takes practice. I recently shared some tips for writing acceptance criteria with a team I’m working with, so I thought I would re-post them here in case anyone else finds them useful.

✅ Good acceptance criteria should…

• List individual, specific outcomes that should be achieved when the task is complete.
• Indicate to the assignee how they will know when they’ve finished the task.
• Preferably be in a bulleted list, with a specific outcome per item.
• Outline the scope of the task (i.e. what is or isn’t expected).
• Be self-explanatory to someone whose only context was gained from reading the task description itself.

⛔ If you’re writing acceptance criteria, you should avoid…

• Describing the aim of the task; this is important, but should be clear from the rest of the description.
• Providing context for the task; this is important, but should have it’s own section.
• Detailing exactly how the task should be implemented; the acceptance criteria should outline the boundaries of the task, without being prescriptive about the implementation.
• Explaining why the task is being worked on; this should be included elsewhere in the description.

💭 When you’re writing acceptance criteria, ask yourself…

“Will the person reading this achieve the outcomes I expect if they complete all of the acceptance criteria?”