Skip to main content

Principles For a Good Documented Acceptance Criteria

Last post 12:28 am March 20, 2018 by Fabio Hidalgo
4 replies
03:21 pm March 19, 2018

Hi All,

I wanted to hear from this group how does a good acceptance criteria look like? I have read a few articles, but also looking to hear from you guys, as there are common principles to be applied, but there's also those different ones. So really looking for a standard (must-have) principles for when acceptance criteria are being put together.

Thanks in advance!


06:46 pm March 19, 2018

The Scrum Guide doesn’t say anything about acceptance criteria, but it does talk about a “Definition of Done” for which the criteria should become more stringent as a Scrum Team improves.

How do you think acceptance criteria might help in defining “Done” for a product increment? From your reading or your personal experiences, what sort of characteristics do you think would be important to this?


10:41 pm March 19, 2018

When I think of Acceptance criteria, I think of it in terms of applying it to the unique testing features of individual Product Backlog Items. Scrum describes it this way: Product Backlog items often include test descriptions that will prove its completeness when “Done.”  I see the Definition of Done being applied to every Product Backlog Item as well as the Increment.

The Scrum guide does not state which technique or tactic to apply for test descriptions.  There are many, and there is no standard.  I have seen teams use the format "I know this is done when..." and then add bullets for acceptance criteria.  I have seen other teams use the Gherkin format for an acceptance test "Given...When...Then".  Some teams prefer to talk about it - the conversation is enough - sometimes called a Three Amigos (Product Owner, Developer, and Tester), although Scrum recognizes no sub teams so we could call it a Two Amigos between the Product Owner and Development Team.

When in doubt facilitate a session to ask the Development team what they prefer.  


12:24 am March 20, 2018

We do have a DoD, and sprint goals, however we probably need a common consensus on acceptance criteria. To me acceptance criteria needs to be transparent, testable (not only for QA team, but scrum team), define boundaries, translate what business through product owner is requesting.

However, seems like each company has their own acceptance criteria understanding, even though all has similar characteristics, and at the end of the day, we need to deliver an increment that will add value to business.

 


12:28 am March 20, 2018

correction: translate what business is requesting through product owner


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.