Principles For a Good Documented Acceptance Criteria
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!
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?
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.
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.
correction: translate what business is requesting through product owner