Acceptance Criteria – Is It Your Team’s Pain Point?

I have been hearing from so many Business Analysts, Product Owners, and teams that writing good acceptance criteria is a big challenge! And, if this resonates with you; you’re not alone! Why is this such a common pain for teams today? I see a lot of mediocre to downright bad practices happening around acceptance criteria, and these poor practices are not helping teams with the outcomes and results they truly desire!

Acceptance Criteria are an important part of any team’s work. Whether you are agile or not, acceptance criteria are critical to understanding, and creating a shared understanding on the team, of what the stakeholders and user need to see, experience and validate before approving and agreeing that the changes (requirements, user stories, etc…) are working as intended and ready to be implemented. For agile teams, this means ensuring that not only are user stories written well, but the acceptance criteria is too!

In the teaching, mentoring, and coaching work I do, I see a lot of repeated challenges. The most common ones I see with acceptance criteria are elaborated below:

When a user story is not written from a user point of view and has other aspects that are not following user story best practices the acceptance criteria will also likely not be following best practices and cause challenges for the team on many levels. The team will struggle to estimate and commit to getting the work done, they will have “story creep” and carry over stories long past the expected time they thought it would take to work on them, and the feedback loops with users will be frustrating. Good user story practices set up the team for good acceptance criteria, and good acceptance criteria positions the team and stakeholders for a positive, trusting collaborative and successful iteration.

For many teams, user stories and their related acceptance criteria are just a list; and many teams struggle with the level of detail.  Healthy backlogs maintain a view from the big picture to the details and the team and stakeholders can easily see how the big picture elaborates on and decomposes into smaller details through user stories and their acceptance criteria. Each level of detail is understandable in plain language to all stakeholders. Many teams are simply not looking at the backlog and product holistically with a product vision and product hierarchy structure that can easily decompose and elaborate on user stories at various levels of detail.  When this is in place, a team can also have accompanying acceptance criteria at different levels of detail for each user story level of detail. This helps the team only focus on the level of detail needed at the time, to make the best decisions possible while seeing the big picture and focusing only on the detail needed at the time the team is working on it.

Acceptance criteria are all about describing what a user is intended to experience, see, and do with the product to achieve the goals set forth in the user story. It’s about the user and the conditions that must be met to be accepted by the user. Many teams misinterpret what this actually means. It is not a list of tasks or actions the team needs do to complete the work, and it is not a list of technical design specs. It is all about the various scenarios a user may encounter and what they see and do within that scenario. As an example, if a user story is about a user “viewing their account order history”, then the acceptance criteria describe the triggers under which a user would view the order history (in the user language, not a technical language), and then what the users see (what data and visuals, not what screens, buttons, and technical widgets), and what the user can do in plain language, not technical jargon.  These pieces change based on the trigger and conditions the user is under. For example, a user with no previous orders will see and be able to do different things compared to a user with orders. Past vs. active orders also may have differences in what the user can see and do. Describing how these various user conditions and scenarios will play out in plain language is what the acceptance criteria are all about.

One other point to note about the definition of acceptance criteria is some teams confuse the “definition of done” with acceptance criteria as well. Acceptance Criteria is unique to a user story; a “definition of done” is something typically defined at the team level and applies to all user stories, so it is more of a quality checklist, and “acceptance criteria met” may be an item on a team’s definition of done.

As many teams shift into testing automation and DevOps they look at how TDD, BDD, and QA automation play with acceptance criteria. Acceptance criteria, when done well, are input to QA practices and can greatly impact the speed and success of QA practices and automation. Acceptance Criteria is also a good input to TDD (test-driven development) and BDD (Behavior Driven Development) techniques and link into these practices and techniques in collaboration with the team. The Gherkin syntax is a common language/format to write acceptance criteria in and when done well aligns quite nice to facilitate QA testing automation, TDD and BDD collaboration as a team.