All you want to know about User Stories and Acceptance Criteria when Building Apps

Featured Image

The concept of outsourcing has become fairly common in recent years with million-dollar companies to even small firms assigning parts of their operations to other organizations who specialize in this business. This has led to a communication gap between organizations especially when it comes to the tech industry and app development.


For example, a company sells custom-made shoes. It wants to expand its operations and wants to develop an app on which people can place their order and track it. Now unless the owner of the shoe factory is a developer-turned-businessman, it is very unlikely that he understands the mechanics of the process. A communication gap will exist whenever he coordinates with the developer team and there is a need that a commonly understood format of sharing information is prepared.




This huge hiccup in the development process can be easily overcome by using user stories and acceptance criteria. Both of these tools help to create a liaison between the layman’s understanding of the process and the technical bits in the coding puzzle.


Acceptance criteria, on one hand, tell the developer what he needs to achieve. He may do it in 5 lines of code or 500, it’s his call. On the other end, it allows the company to precisely express the features it wants to be included in the app. Once the final version of the app is delivered to them, they can test the app against the acceptance criteria and easily judge the performance of the task.



We just discussed two important terms; user story and acceptance criteria. Before moving further, let’s first talk about what these two terms actually mean.



User Story

A user story defines in the simplest manner a feature that you want to accomplish within the app.

Let’s continue with our shoe factory app on which you can configure your own custom-made shoe and place an order.
As a customer, you would want to view the status of your order.



Customer: I want information about the status of my order: whether it is being processed or the shoe has been made or it is in transit.


This simple statement that shows what the customer as a user wants to do with the app is the user story for the product information page.


Acceptance Criteria

An acceptance criterion lays out the process or the steps that need to be performed to accomplish our user story.

Once again, the customer wants to view the status of his/her order.

The acceptance criterion, in this case, will be something like:


I, as a customer, am on the home page of the app. I click on the ‘My orders’ box on the screen and it shows me a list of orders that I have placed. I select the order I want to view and I am shown the status of my order along with order details and expected lead time.


Generally, acceptance criteria are written with major components included in it:


a.) Precondition: The precondition explains the situation or often in our case, the screen the user is currently viewing.

b.) Action: The action shows the options I select or the box I tap or any I activity that I perform to accomplish my intention.

c.) Result: The result identifies the response that the user needs from the app or should get from the app.




The primary purpose of both, the user stories and the acceptance criteria, is to identify what needs to be a part of the app.

  • The user story is a non-technical statement that describes your intention or what you want to do with the app.
  • The acceptance criteria, still non-technically, identify the steps that need to take place to materialize my intention in a more specific manner.


How do acceptance criteria result in better communication?

The concept of acceptance criteria has been serving as an icebreaker between clients and developers (or the app development team and rest of the functions in the company in case of an in-house team). They provide the common ground of understanding between the technical and non-technical people and in turn form the foundation for planning milestones, determining evaluation criteria and formulating payment terms and schedules.


It can be more easily explained by the following points:


i.) Using user stories and acceptance criteria, the company can identify the functions that it wants to be included in the app and the placements and working of these functions. This can help to design the app better by taking input from different departments especially marketing and customer relations who have a better understanding of the user’s mindset and the operations department who are more related to the backend executions once the app is mass-published.


ii.) Similar is the scenario on the developer organization/ department’s end. The user stories layout the features that the company wants to be included in their app. The developer team can then analyze the feature and its implementation as per the acceptance criteria. It provides them an opportunity to suggest a better approach if possible and helps in an overall better understanding of the tasks they should be looking forward to.



iii.) The acceptance criteria in particular help the developer team to identify the tasks they need to accomplish under a certain project and then plan for the upcoming months accordingly.
Comprehensive planning of the human and non-human resources needed alongside a probable timeline will allow them to make realistic commitments with the client and make a more informed decision regarding the price-cost analysis.




iv.) Generally, an app development project can take anything from 3 to 12 months to complete and clients, especially ones with limited technical knowledge find it difficult to understand the time, price, and value constraints. This results in disagreements and discomfort that most people are not fond of.


Having mutually agreed upon acceptance criteria can lead to better management on both ends. Not only it can avoid conflicts, but clients can also make choices about an intermediary version with limited features in case they are in a hurry or if they want to exclude some features if they are running short on budget. The world of business is full of times of compromise and acceptance criteria help in more informed decision-making at such points during the app development process.


v.) Quality assurance is an important step in every app development project. Irrespective of whether a company goes for in-house or outsourced app development, quality assurance is important before the app hits the market. Acceptance criteria provide the basis of judgment during the QA process.


Whenever you are evaluating a decision or a product, you need to have a standard that you can refer to. Since the world of app development is so diverse that it is literally impossible to create standards, acceptance criteria help to devise these standards on a project-to-project basis and ultimately contribute towards timely diagnosis and treatment of major missed-out items, bugs, and hiccups.


All of these points make it evident that acceptance criteria are crucial to the app development process. If you are a company, no matter the size, you need to have the acceptance criteria for your app and agree on it with your developer, whether he/she is a freelancer, a software house, or an in-house team.


When to prepare the acceptance criteria?

User stories and acceptance criteria should ideally be prepared before you contact a developer.


Why so? This is important for your understanding as a company who just wants to develop an app. All of us use smartphones and are aware of the way features are implemented in apps and are presented to us. If you have a list of features, you can easily move from the list to the user stories and ultimately, the acceptance criteria.


Once you are satisfied with the acceptance criteria find an appropriately qualified app developer and share your demands with them to find the best price for your project.


Or you can share your requirements for the app with the developer team and ask them to prepare the user stories and acceptance criteria.


Never make the acceptance criteria during or at the end of the project. Making the acceptance criteria at such a time can not only disrupt the actual development process but also result in a change to the entire scope of work, something that neither the company nor the developer will be willing to witness.


How to make user stories?

Well, this is as easy as telling a story. Think about it as a customer.

Once again referring to our shoe company app, if I am a person who wants some leather boots and opens their app, I should be able to login within an ID that saves my credentials, configure my boots, see the price, place an order. Write these down individually and break them into appropriately specific tasks and you will end up with user stories for your app.


Step1: As a customer, I want to register/login into my account.

Step 2: As a customer, I should be able to open the shoe configurator from the home page.

Step 3: I am the customer who has configured my shoes and now wants to place an order.

As a customer who has placed an order, I want to know the up-to-date status of my boots.


Now that you have your user stories, these can easily be translated into the acceptance criteria.

How to write the acceptance criteria?

For writing the acceptance criteria, take one user story at a time and break it down into the steps that the user will follow to execute the task. Think about it as if you are writing a guide for your user.


There are two methods that are generally followed while writing acceptance criteria:


A.) Scenario-oriented acceptance criteria

B.) Rule-oriented acceptance criteria



Scenario-based acceptance criteria

The scenario-based method follows a cause-and-effect ideology and moves forward while explaining the actions and the consequences simultaneously.


For example, I am a customer who has configured my desired shoe and now wants to place an order.


On the last page of the shoe configurator, when I click on ‘Place your order’, I end up on the order page. The order page asks me to enter my name, contact address, and phone number and select the method of payment. When I have filled the required fields appropriately, I click on place order. Then I get a pop-up message telling me ‘Your order has been placed’.


Rule-oriented acceptance criteria

The rule-oriented method follows an approach similar to a pizza recipe and identifies the steps you need to perform to complete an action.


For example: Once again, I am a customer who has configured my desired shoe and now wants to place an order.

a.) Configure your shoe and click on ‘Place your order’.

b.) The order page will open. Enter your name, contact address, and phone number, and select the mode of payment.

c.) Click on ‘Pace order’. A pop-up message appears saying ‘Your order has been confirmed’.


Both of these methods are equally acceptable as long as they convey the idea of what you want to accomplish with your app. Avoid being too specific with the acceptance criteria and allow some room for the developer to flexibly deploy the feature for you.


And to conclude…

Acceptance criteria are an important part of the app development process, whether in-house or outsourced. They contribute towards a more formalized development process and help to streamline the client-developer relationship.


As a company, always emphasize the preparation of the user stories and acceptance criteria to avoid any inconveniences at the later stages of the development process.

Ready to Take the Next Step?


Rahul Singh

Sr. App Developer

Rahul has been associated with the apps industry for more than 9 years now. He has seen the apps economy grow from its nascent days to a full fledged industry with its complete ecosystem as of today. His interest lies in pursuing and getting to know the best app development technologies, processes and platforms. He is truly an app enthusiast. In his free time he loves playing console games and reading history.

Still have your concerns?

Your concerns are legit, and we know how to deal with them. Hook us up for a discussion, no strings attached, and we will show how we can add value to your operations!

+91-95010-82999 or