Skip to content

Un-acceptance Criteria

November 21, 2012


Like many Product Owners I struggle with writing stories, or to be more accurate, I struggle with the acceptance criteria of stories. In an earlier post I tried to make a point of not writing great stories. Perfect stories will reduce the number of questions, and questions are the perfect measure to determine if someone understands what you want (you then achieve documentation over communication).  Nevertheless, I started digging into the acceptance criteria again. Just to understand what others are saying about it.

Adding no information

The story example above was the first one I found.  And apparently they did read my previous posts, since it hold loads of errors. J The three acceptance criteria listed are really not acceptance criteria from my point of view. The first one, providing a valid id and password is a 100% redundant sentence. It adds no information at all to the original story, and actually covers the happy scenario of this story. The second and third are equally redundant. Yes, we now know we have to create an error, but should case 2 and case 3 provide an identical error? Or should case to make a difference between wrong id and a wrong password? This would typically be covered in a separate story.

So, on the above Story the acceptance criteria example only results in a product owner that looks like a fool. And it is very easy to look like a fool in front of developers.

Hidden epics

Another example can be found at

As a user of the library catalogue, I want advanced search options on the front page so that I can quickly and easily refine my search.

The acceptance criteria are written in simple language that the customer would use, just like the user story. For the example above, the acceptance criteria could include:

  • I can limit the search by format/type.
  • I can delineate the search by date range.
  • I can limit the search to publisher information such as title, author, subject, place, publisher and call number.
  • I can restrict the search to a particular website/catalogue, collection.
  • I can find advanced search options – advanced search options are carried through as filters to search results page.
  • I can filter by availability.

Here the acceptance criteria are abused to add more sub-functionality to the story. So this story actually contains 7 stories. And the top story should be an epic. Each of the above should be split out towards separate stories.

These are the kind of stories that end up with massive number of storypoints estimations.  However nice it seems, the above is really a bad example of what a story should be.

Finding a way with waterfall habits

A third nice example can be found at:

Acceptance Criteria are defined as scenarios:

As an Account Holder
I want to withdraw cash from an ATM
o that I can get money when the bank is closed

Scenario 1: Account has sufficient funds
Given the account balance is \$100
And the card is valid
And the machine contains enough money

When the Account Holder requests \$20
Then the ATM should dispense \$20
And the account balance should be \$80
 And the card should be returned

This is an interesting approach. Reading the story above it tells the developers that they should create an ATM that withdraws the amounts it dispenses from the account balance. These kind of stories are painful left overs of the waterfall age. Those were the days that ‘if it was not written, you are not building it’. As a result you ended up with thousands of absurd scenario’s covering variations of the above. While I believe that taking the scenario approach is right, don’t write out scenarios like the reader is a mental disturbed. Also, acceptance criteria should fit on the back of the sticky note. A final argument in this is that a tester’s job is not to test functionality against scenario’s you write for them.


Concluding I see a number of things in the acceptance criteria:

  1. Totally useless information that makes you look like a fool
  2. Test cases that tells your, very well educated, tester how to do his work.
  3. Sub stories, that should be covered as a separate story
  4. Waterfall leftovers aka cover your ass descriptions. Only there to protect you from people blaming you.

Acceptance criteria can be useful. But I am sure that they are not, if they can be categorized as one of the above 4 categories . Very often you see that they are created as a kind of habit coming from the waterfall age and the misbelieve that you actually can develop functionality based upon a single line and sensible people in your team.

Scrum is based upon a vocal handover of stories. So in the sprint planning and in estimation sessions, the product owner ‘presents’ the stories. This is an essential part of scrum, since it is the only way to convey understanding. Doing this completely removes the need for ice waterfall age kind of specifications.

I know I cannot criticize others without giving my own view on it. Using one of the above used examples:

As a user of the library catalogue, I want advanced search options, using an including or excluding date range, on the front page so that I can quickly and easily refine my search

Acceptance criteria.:

  • Dates manually entered is according to the international ISO date format (ISO 8601)
  • Dates entered via date picker tool should also be displayed according to the official format

No idea what application this would be for, but I do like to hear of my readers if you can come up with more acceptance criteria that make sense. So fire away!


From → Uncategorized

  1. Good article! We will be linking to this great article on our
    site. Keep up the great writing.

  2. Lokesh permalink

    I don’t agree with any of your conclusions. Who are you to decide if something is useful or not. Who are you to decide whether story slicing is correct or not. I strongly believe, assessing user story quality is a very subjective exercise. I have seen criteria like the INVEST criteria, but these are also very subjective and interpretational. The only litmus test I could think of on story quality is whether the same was accepted by development team and whether or not the end user / sponsor was satisfied with the business value delivered.

    • Lokesh,
      Your response is also on of the reasons I like being a product manager. Disagreement is the moment one can learn.
      You write “assessing user story quality is a very subjective exercise”. I disagree. A story has the right quality if helps your team understand what you want. We have learned that conveying understanding through a document does not work, so it will also not happen through a story. No matter how detailed you write it, if you do not get any confirmation back during groming sessions, sprint planning and during the sprint you will not know if it is understood until you see the demo. And functional errors during the demo are the responsibility of the product owner. So trust on communication and use the story as an invite for discussion.
      So, i like to ask you to do an experiment.. stick to single line stories for a sprint, and start asking the team questions to check understanding, look over the shoulders and keep in contact (no, do not disturb the sprint), and see what the result is.
      The great thing of scrum is that the process becomes error-tolerant. So if it fails, it is not a big waste and you have learn something again.

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: