On Acceptance criteria for user stories

One of the teams I have recently coached quickly got a grasp of how to phrase user stories but found it hard to relate to the concept of acceptance criteria.

I wrote this short FAQ as an attempt to make it easier for my team to work with acceptance criteria and hope that other teams might find this useful too:

What’s the purpose of acceptance criteria?

 Acceptance criteria*:

Screen Shot 2015-01-21 at 9.55.44 amDefine the boundaries for a user story/feature



Screen Shot 2015-01-21 at 9.57.38 am

Help the product owner answer what she needs in order for this feature to provide value (typically these are the minimum functional requirements)


Screen Shot 2015-01-21 at 9.58.54 amHelp the team gain a shared understanding of the story/feature


Screen Shot 2015-01-21 at 10.14.55 am        Help developers and testers to derive tests

Screen Shot 2015-01-21 at 9.59.07 am

Help developers know when to stop adding  more functionality to a story



*The little pictures above are created by Nathanael Coyne (@nathanaelb). 


What are good acceptance criteria?

 Good acceptance criteria:

  • State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”)
  • Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)
  • Are relatively high level (not every detail needs to be in writing)


Can you give a good example?

Example user story:
As an internet banking customer
I want to see a rolling balance for my everyday accounts
so that I know the balance of my account after each transaction is applied

Example acceptance criteria:

  • The rolling balance is displayed
  • The rolling balance is calculated for each transaction
  • The balance is displayed for every transaction for the full period of time transactions are available
  • The balance is not displayed if a filter has been applied

Another example user story:
As a 
Snapper cardholder
I want to be able to pick up my pending credit from MySnapper (Note: MySnapper is a client applications for users to top up their ePurse, check their balance etc)
so that I have money on my ePurse

Example acceptance criteria:

  • I can see on MySnapper that there are pending credit(s) for my card
  • I can choose which credit(s) to pick up
  • I can see my new purse balance when I have chosen to pick up a credit
  • I can’t top up my card or buy a pass when there are pending credits for my card

(Personally, I like the “I”-format for acceptance criteria to keep focus on the user perspective rather than system centric view.)

Where do the details go?

What about details such as e.g.:

  • The column heading is “Balance”
  • The rolling balance format is 99,999,999,999.9 D/CR
  • We should use a dropdown rather than checkboxes

These kind of details normally come up in the conversation about the story with the product owner. This would be at the sprint planning meeting or when the team starts coding this particular story.

The details the team capture before coding go into two places:

1. Team internal documentation
The purpose of team internal documentation is solely to serve as a reminder for (potentially forgetful) team members. How much of the details need to be written down depends on the team and whether people write down any details at all is entirely up to them. (Note that this is different from external documentation such as e.g. a user guide which would be part of scope)

2. Automated acceptance tests
Acceptance criteria can be expressed in (almost) plain English for use by the chosen testing framework. This means that tests provide value as documentation, automated acceptance tests and as a feedback loop for developers doing BDD (An example using Cucumber here: http://cukes.info/ )



11 thoughts on “On Acceptance criteria for user stories”

  1. A great to the point description of acceptance criteria. Explained clearly and coincisly without the dribble like most forums. Thankyou very much, found at very useful.

  2. Good example! and excellent post, It helps me to understand a little more. But I have a question, who is the responsible of creating the Acceptance criteria?
    If you are applying TDD, I think the best person responsible of this would be QA team.


    1. Hi Nicolas,

      Thank you for your nice words :-)

      I think that the person who “owns” the user story is also responsible for the acceptance criteria. If you think about that the acceptance criteria really are the boundaries of the story then they need to be defined by the that same person.

      To make sure that the acceptance criteria are good and phrased in a way that testers can derive acceptance tests from them I think it is very important that test /QA is involved in the creation of acceptance criteria.

      So, I guess in terms of your question: I think the story owner is “responsible” for acceptance criteria and QA are “involved”. QA, however, own the acceptance tests.

      In a cross-functional agile team the story owner would be the product owner and QA would be responsibility of the team. Based on your questions I assume that in your context you have a dev, QA and maybe other teams such as BA. In that case I’d have PO/BA own the acceptance criteria and involve the QA team as early as possible.

      I hope that’s helpful.


  3. Hello,

    Quite useful post! Thank a lot . I’m in the process of jumping from the usual ‘lots of FRD’ approach to the Agile methodology and this post has help me to understand more about the acceptance criteria.

    One question that I still have. I come from FRD documents where the documents have tons of details about the widths, pixels, lenghts and all that stuff that defines how a page (for example) will look and behave, which parts are required which not. How do you map that to Agile and stories?

    Do you create an epic and create a lot of stories for all the page details and put in the acceptance criteria the notes for all that details? Lets say for example a sing up form on any site

    Appreciate your help!

  4. What’s Happening i’m new to this, I stumbled upon this I’ve discovered
    It positively useful and it has helped me out loads. I’m hoping to contribute & help different users
    like its helped me. Good job.

  5. Hello, I’m a bit late to this post :)

    I might be missing something here…

    Are you saying that acceptance criteria such as:

    i) options should be in an auto-complete drop-down that is populated from the news feed;
    ii) if the user selects an option the drop down, it collapses and the details from the news item should display in the box below;

    You say these details should be documented in a different place to the user story? And the story should say something like:

    i) user can select a news item

    I don’t see how this helps? These detailed requirements still need to be captured, the developer need to know what to build, how the UX should work, but now these requirements need to be captured in a document that lives somewhere else, in a document that needs to be managed, needs version control, change control, access control etc. And above all, the document still needs to be referenced from the user story..?

    Seems like we’ve added a load of process, added the possibilities of developers guessing, or making judgements, or doing something wrong, and we’ve gained… Not very much, if anything??

    1. Hi Theade,

      The main point I believe is timing. If you only define stories and acceptance criteria to start out with you can defer the details to later.

      Deferring helps us to:
      – Make sure we make detail decisions at a time we (hopefully) know more about the system, feature and users
      – Keep the noise level low so that we can keep an overview when deciding whether/when we should build a story
      – Avoid waste if we decide not to build this story at all.

      Also, the details can be just in the code in the form of tests for example. They don’t need to be in a word document or on a wiki.

      Overall, I agree with you though – the amount of work is probably the same. No shortcuts here … :-)


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>