QA as a strategy: user stories and the importance of acceptance criteria

Acceptance. What is it? In software development, Acceptance Criteria (AC) are the conditions that a product must satisfy to be accepted by a user. These conditions include statements and rules that clearly indicate pass or fail results, and that specify both functional and non-functional requirements. At their core, AC are used to confirm whether a product is complete and whether it is working as expected.

Why do we use AC?

Simply put, to create products that end users will love using. AC allows us to define the right user features, and help with the following regarding those features:

  • to help our clients define what they require in a certain feature
  • to clear up any vagueness about the requirements for the feature
  • to help the team gain a shared understanding of a feature
  • to help developers implement the required functionality of a feature
  • to help developers and testers test the feature correctly

When all the acceptance criteria are met, the feature will be fully implemented.

For example:

AC: In the “Ship Request” page, the user selects “Add More” and is taken to the “Ready to Send” tab to select more packages.

AC: When the user is taken to the “Ready to Send” tab, the existing packages they have selected will continue to be checked. User can select/deselect additional packages.

AC: Once the user returns back to the "Ship Request“ page, the default options will be populated. Any previous changes will not be saved.

When should acceptance criteria be defined - and who should do it?

There are always a few questions that arise when AC are being defined. I.e., who should do it, and do we need all of our AC from the beginning? Can we add more AC for additional features as we go? How do we know if they are correct and valid?

As far as the "who" is concerned, the first role that comes into mind is the product owner. A common responsibility that falls within the product owner role is, in fact, defining acceptance criteria for each user story. The product owner is the person that represents the customer - defining all of the desired features of the end product. But is that the best way to do it? Should only the product owner be responsible for AC interpretation, formation and fixation? Logic dictates that whoever ultimately sets AC has to have an understanding of what end users need, and how this can be designed, implemented and tested. So, if you want to help your product owner, everyone needs to be on the same page on what has to be implemented, how it can be implemented, and how it will be tested. 

At Devbridge, we use what we call the “Three Amigos” strategy. We assemble a three-person team, consisting of either a product owner or business analyst, developer, and a quality control analyst. This team analyzes already written AC and can add new ones from their viewpoints. The success of the product depends on the whole team that is working on the product. We all have our responsibilities, but if we want to implement a successful product, we have to work as a real team, which has the same purpose and understanding. So if we work as the Three Amigos, then AC becomes the responsibility of the entire team. We end up avoiding many questions throughout process.

Now, onto the "when". AC must be written before the implementation is started. That way, the product will be implemented as it was described. Otherwise, the acceptance criteria will be formatted for already implemented functionality in order to verify that it works. However, it is really quite difficult to have a final list of correct AC from the beginning. As they say, "if you go deeper in the forest, you will find more trees". The same applies to software development. After the development process has started, more things become clear: developers have a better understanding of what they cannot implement as expected.

To fix this, we started to organize really productive pre-grooming meetings. Team members gathered and analyzed user story descriptions, attached designs, and examined written acceptance criteria. If something was not understandable for us or a resolution or implementation was unexplained, we made notes. In that way we noted everything that was important for front-end developers, back-end developers and testers. When we had grooming meetings with our PO, designers or clients, we asked these questions, analyzed how things could be implemented, and what way would be the best. After these meetings, our AC lists became more detailed and more accurate.

For example:

Front-end developer

AC: The header should stay fixed in more transitions.
AC: Once the user goes in to profile view, the "Home" icon should morph into an arrow.

Back-end developer

AC: "Ready to Send“ is the default tab that is displayed when user selects "My Suite" or gets redirected to this page.
AC: Tables are sortable by clicking links in the header (From and Date Received). One column at a time (cannot sort on multiple columns at a time).


AC: Required fields: First Name; Last Name; Account Type Name; Country; State (if country with states is selected); Address; City.
AC: Length validation for:

First Name - max 35 characters. No numbers or special characters allowed.
Last Name - max 35 characters. No numbers or special characters allowed.
Account Type Name - max 25 characters, numerical and English alphabet. No special characters allowed.


In order to create a successful product, the entire team has to work as one. Having the same understanding of what has to be implemented, how it has to be implemented, and how it has to be tested is the best way to justify the client's expectations. The AC list, which was defined in a user story, is the most useful way to reach that goal. How those criteria are formed, expanded upon or updated, depends the team. Every team has to find their own way of working together. If you find that way – you're pretty much guaranteed success.