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:

Product Backlog Item (PBI) / Work Item

Example Acceptance Criteria

Clean Living Room

1. Floor is free of dirt, debris, and pet hair

2. Blinds and curtains are free of dust

3. Throw blankets smell fresh and are folded on the couch

So, what’s the difference? The first acceptance criteria point provides an expected outcome; the customer expects that upon return home, after your cleaning service is done, the living room floor will be “free of dirt, debris, and pet hair.” The cleaning team may vacuum, mop, or even use a lint roller on the entire floor to attain this outcome, but that’s not important here and how the outcome was attained is completely up to the people doing the work. The customer is simply defining what they expect.

The next time you are asked to define acceptance criteria, remember this example. Acceptance criteria does not need to be extensive and it is not intended to be difficult to create. If you are the customer or working closely with the customer, it’s one simple question: “What is the specific outcome I expect when this piece of work is delivered?”

Use Case 2.0 – The Perfect Solution to your Agile Requirements Problem?

Read Now
Elyse Platt
Elyse Platt