The easy way to write the best user stories

Jointly writing user stories with the team is one of the things I enjoy most about being a Product Owner (PO). This written communication is one of the key skills that any PO needs to possess. Writing a user story is not rocket science. Nevertheless, it is a point of significant leverage for the success of product development and I feel that the task is undervalued. Thus, this post on how to write user stories.

First, what are user stories and why do they exist?

Email address:

Leave this field empty if you're human:

Why user stories

A user story serves a few purposes. The most straightforward is probably that it is a very simple explanation of what needs to be developed for whom and for what reason. As such, it is a vehicle for communicating high level requirements between team members, PO, and stakeholders.

One could argue that this discussion is actually the main reason for the existence of user stories. The point is not to write them. The point is the communication they cause between users, developers, PO, and other stakeholders. Ideally, this leads to simpler, better, and more valuable product improvements. In this context user stories help keep the discussions focused on the core user problem that we are trying to solve.

What is a user story 

A user story is a short and precise description of what needs to be developed for whom and for what reason. It should be the smallest product increment that delivers some sort of value to a user. A story is independent, i.e. it should deliver value by itself, and is written in such a way that it can be implemented by anyone within the team.

There are many (similar) ways to formulate user stories. I tend to give them a small title that explains the core functionality. Then, I write one simple sentence that explains the product improvement:

As <some user> I need <something developed> so that I can <receive some sort of value>.

With this very simple structure you are able to answer three questions.

1. What needs to be done?
2. Why does it need to be done?
3. Who needs it? 

The user in this case can be internal or external. I used to be PO for a Business Intelligence team. This team almost exclusively created value for others inside the company. The team I am currently working with is building a B2B service and we are thus creating value for externals. 

Technically, the team itself should not be the beneficiary of user stories – at least that seems to be the official stance. However, I really don’t see a problem with that, as long as those specific stories are not too frequent and will lead to value for others down the road.

What is not included in a user story?

As mentioned above, it is crucial that the user story answers the Why? Who? and What? questions for product increments. Equally important is that it doesn’t answer another question. How is the goal achieved? This should be left up to the team!

Also, a user story is not a list of requirements. As you will see below, it can be enhanced to include specific requirements in the form of acceptance criteria. However, by itself the user story is already sufficient to start discussions and implement a solution.

(Non-) Functional Requirements

Besides the user story, a product increment may need to satisfy specific requirements. These can be functional, i.e. they give more detail to the core functionality in the user story. They can also be non-functional, i.e. even without satisfying them the core functionality within the user story can be implemented. 

Generally, non-functional are not necessarily needed to fulfill the core user need in the short term. Nevertheless, they may be needed to make sure the product functions in the long term. 

Non-functional requirements are often defined within the product development team(s) or are according to industry standards. Typical requirements in the IT sector are product performance, test coverage within the code, scalability of the application, or security standards that the product must adhere to (there are many more).

I tend to use two different ways of dealing with requirements: 

• Acceptance criteria
• Definition of Done

Acceptance criteria

Requirements that are specific only to a single story can be included with the use of acceptance criteria. They are clearly stated conditions that must be satisfied for the story to be completed. 

For me, the acceptance criteria usually come up in discussing user stories with the development team. I have found that they help by creating some sort of boundaries for development. However, I suggest not to use too many so as not to give too many limits. In our case, we tend to include roughly between one and five acceptance criteria in each user story. 

As for the user story itself, acceptance criteria only include what needs to be developed and not how it should be done. This cannot be emphasized enough. One of the main mistakes made by POs, especially if they have a technical background, is to focus on the how instead of the what and why. I frequently fall into this trap. Trust me though, the team knows this better than you 😉 

Definition of Done

In comparison to the acceptance criteria – that are unique for each user story – the Definition of Done (DOD) is a set of requirements that are valid and identical for each new development. It is not defined specifically for each story.

Instead, the DOD is a universal list of things valid for each story that all need to be completed before a user story is considered as done. It is defined by and for each team and will differ between teams in the same company.

Since the DOD always applies, it is a very good place to include the non-functional requirements that should always be fulfilled. This helps to ensure a consistent product quality. Some examples of requirements that I have seen included in DODs:

• The software is deployed to production
• A certain test coverage of code is achieved
• All tests have passed
• Stakeholders are informed
• All acceptance criteria are fulfilled
• Documentation is up to date

Breaking down stories

The individual story is frequently created when larger items in the product backlog are broken down. The goal here is to split large improvements that include many requirements into the smallest possible product increments so that they can be implemented quickly, within at maximum one sprint. This is done to a) deliver value as often as possible and b) to gather feedback as rapidly as possible. 

This breakdown of large backlog items into smaller stories is where the effectiveness of product development is greatly impacted. The way that requirements are sliced is in my view one of the main features of agile product development. 

If the story is too large to be done by one person, if the team is not able to complete the full story in one sprint, or if you have more than a handful of acceptance criteria, you very likely need to split the story into multiple smaller increments. This is oftentimes not easy but so valuable. 

The process of creating user stories

A user story is created iteratively in a collaborative process. It is not done only by the PO! However, in practice the PO is oftentimes the person that creates the initial version of the story that is then jointly refined. In many teams the refinement ends with an estimation of the story. It is then implemented.

Currently, we are using a multistep process that starts with a high level estimate of the epics (i.e. larger work packages) that are planned in the next months. In this step we only discuss the general idea of what is to be achieved and sometimes create some initial stories so that we all have the same understanding of what the iterations of the epic could look like. 

The outcome of the high level estimates is a rough number of sprints it will take to implement the solution. This number often changes later on. Nevertheless, I use it to build a roadmap and communicate the plans for the product within the company.

Once we get close to implementation of the epic, we jointly create and refine the individual stories. Generally, I try to do this no more than two sprints before the development work is done. During this refinement, we have very intensive discussions and define what the stories, the product increments, are going to be. In this process, we split and merge, delete and create stories. In the end, we (hopefully) end up with any number of independent product improvements that are ready for implementation.  

Additional information

There is all kinds of information that can help in the implementation of the story. After specifying the user story and acceptance criteria we often add this. We may add things ranging from test cases through mock ups, user flows, and API documentation all the way to something like “Ask Bob for tips, because he has done something similar before”. 

The goal is here to make it as easy as possible for the developers to implement the feature. If you are using any of the prevalent software, this is of course much easier compared to using physical stories, since you can just paste links, files etc…

The end result

When we are writing user stories, we frequently end up with an end result similar to the picture below.

We always have some sort of short title that explains the core functionality. Then, the actual one sentence user story describes the why, who and what. We generally have a handful of acceptance criteria to set some boundaries and include non-functional requirements. Very often, we also add additional information. 

Don’t overthink it

I now wrote over 1500 words on how to write user stories and I am not sure how I ended up with so many. It is really not that complicated and I urge you not to overthink it. 
Write down what needs to be achieved in the format As a user I need…, specify a few acceptance criteria, and add any other helpful information. That’s it! The process that follows, the discussions with the developers, re-writing, splitting and merging stories, and in the end, of course the implementation, is where the magic really happens.