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 am

Define the boundaries for a user story/feature


Screen Shot 2015-01-21 at 9.57.38 amHelp the product owner answer what they need in order for this feature to provide value (typically these are the minimum functional requirements)



Screen Shot 2015-01-21 at 9.58.54 am

Help 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/ )



Sandy Mamoli
  • LiNk MaN

    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.

    October 8, 2012 at 12:41 am
  • David

    Great introduction to acceptance criteria! Thanks! A must read for all my team members.

    December 12, 2012 at 3:31 am
  • Nicolas

    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.


    August 30, 2013 at 8:05 am
    • 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.


      August 31, 2013 at 11:09 am
      • This is an excellent clarification of how QA is involved in User Stories. Thank you for the comment, and of course for the great post too!

        July 15, 2014 at 8:59 pm
  • Daniel


    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!

    September 5, 2014 at 11:55 am
  • [主页]

    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.

    September 14, 2014 at 12:27 am
  • Theade

    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??

    January 16, 2015 at 3:28 pm
  • Jessica


    This (and your other) article on Acceptance Criteria has been a lifesaver! One quick question, when should they be written? I am working as Product Owner and populate stories in a backlog with acceptance criteria as I know them, but sometimes clients provide feedback that may affect the acceptance criteria.

    My question: Do acceptance criteria need to be written and set in stone at the sprint planning session, or is there flexibility to update these during the sprint?

    Thanks much!

    August 20, 2015 at 2:44 am
  • Beau Garcia

    A sound and pragmatic approach to acceptance criteria. A future article might include the given-when-then approach vs the one above. Comparing these two methods might expand your readers horizons. Nice work.

    August 28, 2015 at 12:04 am
  • Binary choices always have a managed risk-to-reward
    ratio, that means the risk and reward are pre-determined on the time the
    contract is acquired.

    December 13, 2015 at 11:49 pm
  • Stephen Doggette


    February 3, 2016 at 6:19 am
  • Hari

    Sandy It was very great explanation. Thanks.
    I have a question here. Can an Tester define/write the Acceptance criteria by going through the requirement/user story overview and solution design. Basically if we do not have any acceptance criteria defined and only the solution design is briefed. I’m asked to prepare the acceptance criteria for the sprint stories. I guess this should be done by the product owner/business analyst for the sprint. Please brief me.

    Appreciate your response.

    July 13, 2016 at 11:16 pm
  • Liddie Afork

    Helpful blog post . Apropos if people have been needing a MA DoR 1 , I edited a template form here http://goo.gl/THVwd9

    September 7, 2016 at 3:12 pm

    I am new to Agile and the article really helped me to get a better clarity on the acceptance criteria for my user stories. Thanks!!!!

    March 13, 2017 at 4:59 am
  • I don’t agree with this: “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.”..
    All details should be defined even before the sprint planning. This saves time, i.e.,during sprint planning, and during development. The development team doens’t need to keep asking the product owner about possibly undefined functionality.

    March 30, 2017 at 10:49 pm
    • Raj

      I agree with you 100%. As a product owner, I can tell you my development team can’t even do proper estimates if details are not there.

      April 1, 2017 at 4:09 am
  • Farhan Sabir

    Is there a need of test cases as well when there is acceptance test? Test cases are more detailed than anyone of this. Should we include that as well?

    April 7, 2017 at 12:58 am
  • Shan

    Hi Sandy

    Thanks for this post about acceptance criteria.
    I would like to ask doubt about “Test cases”. You have mentioned about details like header, display format , precision, etc would be mentioned in “Internal team documentation”, “Automated acceptance tests”.

    Can we say that test cases or Acceptance test would be derived from acceptance criteria and cover the details by referring to details captured in “internal team documentation”?
    1) [Given] valid user having 1 savings account lands on “xyz” page by clicking on “abc” menu
    default value of “Account” drop down is “–select–”
    [When] clicks on account drop-down
    [Then] user’s saving account number is displayed in the drop-down list

    2) [Given] user account has sufficient balance
    [When] user selects the account from drop-down of account
    [Then] Balance is displayed in the defined format (refer to screen design document “123.xls”)

    May 9, 2017 at 6:14 pm
  • Cool post, do you mind if I share this on my site?
    It is Dynamite Indicators. I will be sure to post a link back to the original post?

    July 10, 2017 at 2:24 am
  • Shahab

    Hi Sandy,

    (long time no see, since our course with Lyssa here in Stockholm )

    Great summary of Acceptance Criteria. Useful with good and clear examples!
    Actually, I was looking for something else when I found this blog and could not just pass it 

    But I still have my question on User Story. I write my question (That I was looking for an answer in the web). Let us see anyone care to answer.

    We had quite interesting discussion with our coach colleagues today.

    Does “As a …..” needs to continue always with an actual person, i.e. a customer or a user, etc
    Couldn’t it continue another product or even an organization?

    Let’s say we are hired by a company that just wants to start its change journey of agile.
    Well, we need to have list of things that need to be done!
    The user story (or maybe the epic, based on the size) can look like …

    As an organization just starting the agile journey, I need to have a journey-backlog to make sure we are going forward in our journey …
    Then of course some AC to it.

    What do you think?
    Any reason saying that it is right or wrong?

    August 22, 2017 at 3:05 am
  • Brian

    Hi Sandy,

    Interesting post, and I happened to stumble across this. I am interested to understand more about the business people’s role in this (the ones sending feature requests for increased business value).

    As I have understood it, user stories is a valid way to make user intent and business requirements more understandable for POs and development. How can the business person, the stakeholder, prepare their needs for POs to minimize the amount of misunderstanding so development doesn’t do the wrong things from the start?

    How can acceptance criteria be used during a release cycle? Validating these in the end as a stakeholder would definitely be a tiresome process (large testing backlog for user acceptance testing and higher risk that deveopment might have done the wrong things).

    Can the stakeholder use these acceptance criteria as manual test cases when they validate the new features right before release?


    October 13, 2017 at 3:17 am

Post a Comment