So someone recently asked me:

“What role does acceptance criteria play in modern software delivery?  And who is responsible for writing it?  Where should it be documented?  When should it be done?”

Thoughtful questions.  My reply:

Wow what an interesting question.  Whole books and a million blog entries have been written on this topic.  I will try to summarize that world of knowledge in 10 bullet points or less – let’s see how I do.

1. The more people who participate in the development, the more you need to document and write things down because you must move from pure communication (few people, many have interest) to coordination (many people, few have interest).
2. The “story” has stood the test of time as having a role in modern software delivery, but is an often misunderstood child and sometimes abused.
3. The heart and soul of a “story” is as a “placeholder for a conversation”.  The more detail you put into a story, the more coordination and less communication you get and vice versa.  The following is my advice to any team as to what level of detail is needed in a story:

• Enough that you can estimate the amount of work
• Not enough so that you are forced talk to each other to bring the story to life

4. So what about acceptance criteria (AC)?  The nirvana of AC define the behavior of the software independent of the implementation. Often such criteria are easily automated, but not always.  An example.  A deck of cards should have as many cards as that type of card deck.  So a poker deck has 52, pinochle has 48, etc.
5. So what role do acceptance criteria play? AC tell you when you are done with the functionality of that story.  What happens when you meet the AC but there are more behaviors that are needed?  Going back to our deck of cards example, a poker deck has an equal mix of 4 suits.  Write another story.  Can you say, *incremental*?  What if I hard coded the numbers and met the AC?  Such software is not maintainable, easy to change, etc so when I do my code review (either by myself or with a team member), I need to refactor (perhaps read the number of cards per card deck type from a JSON file).  Can you say *iterative*?
6. Who is responsible for writing AC? Everyone can.  Some teams work very effectively by having a select few (sometimes a business analyst, sometimes a senior developer) write AC.  Writing AC requires functional knowledge and design (software architecture and user experience) skills.  Here is my advice to a team.

• Design is an activity for most stories
• Few are masters at it
• Design in isolation at your own risk

If you are using Kanban, then make a lane for Design and pull the stories through it balancing the “who” against your WIP.  If you are using Scrum, then during your planning activity, write the AC as a group sport.  If you are using XP, the customer creates the story and the team talks to the customer to get the acceptance criteria when they work the story. If you are using SAFe, well, SAFe really relies on a Scrum, Kanban, and XP at the team level, so nothing different.

7. Where should it be captured?  My personal preference is always low tech, high touch.  So I like the back of the story.  However I love it when the AC are captured by automated tests.  So if I was king I would say:

• AC are created first on the backside of the story
• AC are then automated and are therefore captured in the code

Personally, I am not a fan of capturing them and imprisoning them.  AC rarely affect coordination and always affect communication.  Therefore there is little to be gained by writing them down or remembering them.  If they are important enough to want to write down, then there should be an automated test that is capturing that AC. A notable exception is as your project size increases, you may need to write them down and coordinate them across multiple teams or user groups.  However after they are implemented, writing them down will do little useful other than to gather dust.

So how did I do?