In agile software development, adaptive planning, evolutionary development, and constant communication between the teams and the customer are just a few practices aiming to improve the efficiency of the software development process. One important aspect of agile software development includes the writing of user stories.

By creating user stories, you give your team and product owner a better understanding of who the product is for and what value it brings to them. Further, when writing user stories, you essentially break down the product into several functional components that can be worked on and implemented in any order, rewarding your project with much flexibility and small, steady accomplishments. To get the best out of your user stories and increase your team’s efficiency, we will show you some important factors to keep in mind when writing them.

What are user stories? How do they benefit app development?

In agile software development, the teams – in consultation with the customer or product owner – divide up the work to be done into so-called user stories. These stories are short, informal, plain language (non-technical language) descriptions of what a user wants to do within a software product to gain something they find valuable. As the name suggests, the stories are written in the perspective of the future user of the product, putting them at the center of the conversation.

The 3 Cs of a good user story

You can essentially divide the user story into three components – Card, Conversation, and Confirmation.

Card: The card – often a Post-It note – serves as a physical token and gives the abstract idea of a certain function or feature a tangible form. This form usually follows the role-feature-benefit template:

As a (type of user) > Who are you building this for?

I want (an action/feature) > What are you building?

so that (benefit/value) > Why are you building it?

You can see, the user story aims to answer the three questions of „who“, „what“, and „why“. With an example, the story would look like this:

As a customer (of an online shop)

I want to be able to view a list of products,

so that I can quickly find what I am looking for.

Conversation: Writing user stories requires much collaborative communication between everyone involved with the production (product owner, developer teams, testers etc.), so that everyone understands and agrees on the functions and features each respective story aims to provide. It is best to hold these conversations as much as possible in person in order to avoid any misunderstandings. Further, these conversations can and should be supplemented by documentation and acceptance tests (we will talk about those later in the article).

Confirmation: The product owner must confirm that the story is complete before the team can start to implement it into the product. Here, it is important that both parties (product owner and team) have a common understanding on the definition of „complete“. On top of that, the associated acceptance tests should all be in a passing grade

User stories don’t go into a lot of detail – the requirements are added later – but after reading these stories, the teams know why they are building the product, what they are building, and what value it creates.

Further, since user stories are small self-sustained units of work, they enable the teams to enjoy small wins as they complete one after the other. Adding to this, each user story is independent in nature, allowing you to implement them in any order that you like.

How to write good user stories

The role-feature-benefit template portrays the basic form of a user story. But simply filling out the template is not enough. Before you or your team start to implement the feature, you should first test whether the story is well understood and ready for implementation.

Keep the INVEST-checklist in mind

A perfect checklist has been provided by Bill Wake in 2003: the INVEST acronym. Each part of the acronym plays an important role to consider when you write user stories.

Independent:

The first part deals with the independency of the user story. The stories should be independent from each other so that they can be freely moved around your product backlog as priorities shift.

Negotiable:

Lay down the details of a user story in collaboration with your team and the product owner and talk about the scope of the story. Which functions will the implementation include, which will be omitted?

Valuable:

The user story needs to have value to the product owner. Without value, there is no point in putting any effort into the story.

Estimable:

You need to be able to estimate the story. If you can’t, it is possible that you either don’t understand the scope well enough, or the scope is too big to estimate. A story, whose size cannot be estimated, cannot be negotiated with, either and will probably never be planned or tasked.

Small:

The effort to implement a user story should be small. A story should be finished in a few person-days, at most in a few weeks. A good rule of thumb is that each single story should not take more than 50% of an iteration. For example, one story should not take more than 5 days to complete during a 2-week sprint.

Testable:

The last step in the checklist involves the testability of your user story. The story should only be considered done, if it was tested successfully. If it cannot be tested, or if it did not pass the agreed upon tests, the story is not ready for implementation.

Acceptance criteria

Following the topic of testability, we will present you the last requirement for a good user story: the acceptance criteria, or ‚conditions of satisfaction‘. They provide a detailed scope of a user’s requirements and further help the team understand the value of the story, and set expectations as to when the team should consider the story to be done.

Acceptance criteria aim to ensure that everyone has a common understanding of the problem or need of the user. They help the team members know when the story is complete and verify the story via automated tests. The criteria should, among else, include the following:

• Negative scenarios of the functionality
• Functional and non-functional use cases
• Performance concerns and guidelines
• The impact of a user story to other features
• End-to-end user flow
• UX concerns

Finally, an example of a completed user story with acceptance criteria would look like this:

User story:

As a customer (of an online shop) I want to be able to view a list of products, so that I can quickly find what I am looking for.

Acceptance Criteria:

• The user can scroll through a page containing a list of purchasable items
• The user can sort the list with filters and categories (price filter, gender, brands)
• The items should be presented with a picture
• A price tag should accompany the items
• A star rating should be included under the product’s picture

Here, we have a complete user story with its acceptance criteria. Of course, it is possible to add more criteria, or edit others – it depends on your team’s and customer’s mutual understanding on what the story should do or not do to be considered complete.

Conclusion

User stories play a huge part in agile software development. They provide a framework for the team to work on that puts the end user at the center of the conversation. Additionally, by dividing the product into these components, the teams get a better understanding of the context of each and every feature. The writing and implementation of user stories enables thorough collaboration and communication between all parties involved, and through that, increases the team’s productivity and the product’s overall quality.

This is why the process of agile development – and with it, the writing of user stories – is a set of practices that we have been successfully utilizing in many instances. Therefore, if you need support in managing the development of your application, or if you need some advice on how to improve existing user stories for your product, feel free to contact us – we are eager to work with you on your project.