Writing Great Acceptance Criteria

When it comes to acceptance criteria, you want just enough detail that the customer can accept the work item as “done” without telling the team how to do their work. People frequently ask about tips and tricks for acceptance criteria; you may hear recommendations to approach using the commonly-known SMART (Specific; Measurable; Achievable; Relevant; Time-bound) criteria or maybe you’ve heard about INVEST (Independent; Negotiable; Valuable; Estimable; Small; Testable) for writing user stories or product backlog items.  I take a simpler approach when I coach because I’ve seen teams struggle and end up taking a exorbitant amount of time on this task.

For example, a team I worked with recently ended up abandoning the traditional user story format and listing detailed, step-by-step tasks of how they intended to complete the work item as the so-called “acceptance criteria.” You may see resemblance between tasks and acceptance criteria as you practice, but let’s focus on the purpose of acceptance criteria not the format to ensure usability. Again, acceptance criteria is essentially a set of requirements or measurements that specify how the customer can accept the work item as “done.” Careful, in an Agile world with extensive, up-front requirements documentation; that is not to be confused with just-in-time planning and definition. We can cover more on that topic in another post.

I once heard about the residential cleaning service example and have since tailored it and added more detail to explain this concept to the teams with which I work. Imagine your team has been hired for a residential cleaning service. Let’s look at one example work item: