This is going to be an ultimate guide for writing a clear and concise user story acceptance criteria.
Before we look into it technically we will have an idea of its concept. Take a simple example where you want to get a flat for yourself. You must have some specific requirements in your mind regarding the flat. You can be requiring a two room flat. Or a flat with a school nearby because you have kids with you. Or it can be any such thing which needs to be there in order to meet your needs.
Likewise when we are designing a product, we need to have in mind certain criteria which the product meets. The product should have the specific features which should provide a solution to the end user of the product. Let’s see why this is important and what the best practices to curate the best piece are.
What is user story in user story acceptance criteria?
We used the term user story, but what this term means? Let’s see it with an example too. Suppose you are using a mobile application which lets you record your finances. All your debits and credits are recorded in it. So that you can manage your expenses and plan accordingly. In short it is a financial management app. As the user of this application you want to download your financial statement too. So that you share it with your family too. This is the user story.
It is a brief description of the feature you want in the present application. What and why you want a certain feature is basically a user story.
The user story is an important element for the product designers. While designing a product, the team members can know the end purpose of the product. And keeping in view the same they can be on the same page. Let’s again put it in simpler terms. Actually when the developers design a product, it should be a solution to a user story (the problem).
What is acceptance criteria in user story acceptance criteria?
Acceptance criteria is basically a type of an agreement between the user of the product and the designer of the product. The user accepts the features and the designer agrees to deliver the same. Acceptance criteria helps the designer to make a product that is accepted by the user.
Again let’s understand this by extending the above given example for the user story. When we wanted to download our financial report we need to have different options. What can be these options? Suppose you only want to download the debits, or only credits, or you want to download from a certain date to a certain date. Also, you may want to download the report in different formats like doc, excel, or pdf. These are all compiled to give us the acceptance criteria.
Do you think this is complete? There are some options still missing. You should also be able to name your report before downloading. Also, after downloading you should be able to share it with your family. Now we can say that the acceptance criteria is all completed.
Best practices to write user story acceptance criteria
Now it’s time to look at the best practices to write the acceptance criteria. Before, we need to know that there are two basic types of writing an acceptance criteria. One is the scenario-oriented and one the rule-oriented.
Basic types to write acceptance criteria
Scenario-oriented type
In the scenario-oriented type, we are given a certain scenario and then a solution to it. Suppose we forgot our password to enter our account on the same financial app we have been discussing before. Here we are given a certain situation where we are now stuck and we need a solution to it. The steps where a user clicks forgot password button, enters his email, gets a password reset mail, and then reset it by entering a new password. This all forms the acceptance criteria.
Rule-oriented type
Let’s skip to the second type now. Suppose in the same app, you now want to find your credits and debits on a certain date. This is a search criteria. To use this feature you need to have this advanced search option. And here you apply the rule oriented type. Here things like having a search bar, the search options, and selecting a date from the built-in calendar forms the acceptance criteria. Also, you need to form a function which gives you a warning message something like “invalid search” when you either don’t enter or enter some wrong information regarding your searching filter. All this forms your acceptance criteria.
Implementation to curate best user story acceptance criteria
The time to discuss the best practices is here. Let’s have a look on some implementation to curate the best piece.
Use shorter and simpler sentences
We should try to use shorter and simpler sentences. It should be clear and easy to understand. The team of product designers should be in a position to understand in a precise way the needs of the user.
Use small number of user stories as the foundation
In the start it should be based on a smaller number of user stories. To avoid the complications this practice is the best. It makes the planning for the technical process of product designing very easier.
Should have the elasticity
Acceptance criteria should not be too specific. It should not be as such that limits any scope of changing it in future. It should retain the option to make any changes to meet (all) the needs of the user.
Should be in plain and easy language
It should be written in plain language. No technical language should be used as there is a possibility that it may lead to any confusion. There can be some members from the product designers’ team which are not aware with the technical terms.
Avoid negative sentences
You should avoid using the negative sentences. By it I mean using the word “no” too often. Take the same above example of the financial management app. Writing, that, entering the incorrect search filter should not show the error message in blue color is a wrong approach. Rather say that the error message should appear in red color.
Break the acceptance criteria as one per line
Break the acceptance criteria as one criteria in one line. There should be a clear solution to each criteria and a clear why to every feature.
Key takeaways
This was all for this article. It is useful for bringing the product owner, all the stakeholders, the product designers, and the end users on the same page. It helps to save time and money. So, you get a clear reason to use the user story acceptance criteria next time you plan to launch a product, or a software. This term usually applies to the software development but is a general term and can be used with the services and products as well.
