Acceptance Criteria: Won’t Save You From the Zombie Apocalypse, But Still Useful

Acceptance criteria are a very important part of user stories. While the story itself tells you what a user needs, the acceptance criteria give it context. You get the business need and a set of statements describing the customer’s expectations so that you can better ensure their acceptance of the final product.

So, let’s take that Jaws example again.

As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.

One of my developers might just rush through to work on this and cut it open right there on the dock. THAT IS A FAIL. That is not the time or the place to perform some kind of a half-assed autopsy on a fish… And I’m not going to stand here and see that thing cut open and see that little Kintner boy spill out all over the dock.

Maybe you give it a little clarification.

As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.

-do not cut open on dock

Huzzah! Some specification! Now when the developers come to me to talk about this story and complain about having to drag a two-ton fish elsewhere to clean the license plates out of it, I can tell them why it’s a bad idea to rush into this one. To look at this from an actual software perspective and stop talking about sharks for five damned minutes, let’s look at this example:

As a lab clerk I need to be able to add a referring physician to a case so that the diagnostic results can be sent to all appropriate parties.
– user should be able to select referring physician from a list of physicians associated with the account
– user should be able to add new if physician is not available

This is pretty good acceptance criteria. The story is clear enough, saying that they need to be able to add a referring physician to the case, but the acceptance criteria specify how they get that referring physician. There is going to be a list of physicians associated with the account, so a user can choose from there. If we made them type it in each time, it would be hella wasteful and a poor use of their time. Choosing from a list dramatically speeds up their process and avoids QA issues later when they’ve typed the name incorrectly (all. the. time.). But what if the physician is not on the list, you ask? Why, the user can add a new one! Fantastic. The lab clerk can now quickly add a referring physician to this case without a) stopping to have someone add a new physician in the database or b) manually entering physician data for each physician they want to add.

Now this acceptance criteria has given us something very valuable: testability. With more context to this story, our QA team has more to verify and more scenarios to run through. They know that they need to test whether or not there is a list of physicians associated with an account, that a user can select one from that list, that a user can add a new one, and that a new physician added should be automatically associated with that account to appear in the list later (by virtue of being added in line to that case which belonged to that account). We have given this story context and testability, and I don’t think developers would have any problems building this story out. Additionally, the developers will be able to write better tests for the story as they are developing it. It gives the developers a benchmark to hit before they pass a story off as code complete. Testability is really an overloaded term that includes “benchmarks against which we can test our expectations.”

Now, be careful. Acceptance criteria can get ugly and unwieldy fast. You’ll start specifying things like “user should be able to press button to access report,” “there should be a save button that writes the referring physician to the database,” or “referring physicians should be linked by ID to accounts.” These are classic rookie mistakes. Acceptance criteria should not specify design; it should specify outcome. If there is some very specific design you would like to see, mock it up and attach it to the story. (Balsamiq [] is a great mockup tool.)  The second example of suck that I gave was a classic example of overspecification.  This is something that happens all too often when writing out acceptance criteria.  Read back through your criteria, and if something makes you say “well, DUH,” then it’s just noise and the developers don’t need to see it.  Keep your criteria clean and simple and to the point.  Noise reduces signal.  Noise is bad.  The last example is another mistake that is made all too often; specifying implementation details.  You are writing the story from the POV of a user; leave the implementation details to the developers.  This is not to say that you shouldn’t always leave out implementation details; sometimes things are necessary to make sure everything fits together.  Find the sweet spots between all that crap you want to put in there and the stuff that really needs to be in there.  It takes time, and I am still guilty of all of those things, but practice makes perfect (or so They tell me).

One of the best things that has happened to our acceptance criteria is involving the developers.  When we do team planning the developers and QA team are bound to catch things that I have missed.  You won’t always get everything right off the bat and you might not get it all yourself; collaborating with your team will help to ensure that you’ve caught everything.  Meeting with your team just before time of development to discuss things will make sure that you have all of the requirements correct and that you will have all of the information.  If you meet early on, requirements may change and your customer might decide they want something completely different (all. the. time.).  Specifying close to time of development will ensure that everything is as accurate as it can be, to the knowledge of everyone involved.  It’s perfectly acceptable to see the acceptance criteria grow during all phases of development. New information will surface as the team looks at and implements the story, and new expectations will be set. This is ok, and good, and desired because it means the team is coming together to ensure delivery of quality systems.

What acceptance criteria should not be:

– Design details

– Implementation details

– System language

– Overspecification/noise

What acceptance criteria should be:

– measurable

– testable

– descriptive of outcomes > implementation

– individually realistic and realistic as a group

– expectations (especially for a customer)

Not all of these things will work right for your team. Maybe you need some implementation details in your criteria. Maybe a little system language is necessary. That’s ok. One thing I have learned (and still hate) is: “it depends.” Everything is subjective depending on how your team is, things vary project or project (or even story to story), and it’s an uphill battle to hit the nail on the head every time. Take a deep breath, use your best judgment, and refactor it til it’s good.

6 comments so far

  1. David Laribee on

    “Additionally, the developers will be able to write better tests for the story as they are developing it.”

    We have a pipeline for each story where developers put acceptance tests into a “ready” state. Our QA resource then verifies and places tests in a “pass” or “fail” state. They also decide whether or not to automate tests.

    We call acceptance criteria “specifications” and are pretty loose about them after having gone the apprentice route of GWT/Context-Specification for 6 months.

    Our UX people often write interaction/design specs in screen language. You say not to do this, but it works OK for us given we have dedicated UX talent. Even so, I’d call this a compromise as we work toward getting production-quality wireframes to engineering.

    Nice post. Keep ’em coming.

  2. Efraim on

    My process is simple:

    Think it up using

    If needed, make it nice using:

    Snap a picture, send it to your outsourcers on:
    and have them make a prototype

    Usertest the prototype

    Build it

  3. Scott Bellware on


    When a person is cutting into a shark to see if that little Kinter boy is inside, are they acting in the role of oceanographer?

    A person’s role isn’t their job title, it’s their role – within the context of a story.

    What if a paramedic living in a beach town with a visceral sense of shark viscera were to cut open the shark?

    I’m not saying that within the context of your story that the role should or should not be ‘oceanographer’, but it raised some questions in my mind.

    • Janaya on

      That’s way the bestest anwers so far!

  4. […] Muddying up the spec will make other items of actual importance get missed, noise reduces signal, yadda yadda yadda.  These are items that we have just determined will be standard, and as we get new additions […]

  5. corningware on

    This site definitely has all the information and facts
    I wanted concerning this subject and didn’t know who to ask.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: