The five most common mistakes when writing user stories

User stories are a popular method used to record software requirements, especially in agile frameworks like scrum. The product owner – ideally provided by the customer – formulates them and conveys them to the development team so that the team can work through all of the requirements – referred to as the product backlog – step by step. The product owner prioritises the individual user stories and is responsible for the budget for the software product. Moreover, the product owner is also the person who knows the precise needs of the end users. As such, the product owner plays a key role in agile software development – and in the user stories formulated: “The product owner must be able to express their intentions and requirements with the user stories”, explains Marko Marković, Senior Software Engineer at bbv. “If they do not succeed, the development team might misunderstand the user stories. Subsequent improvements are then needed in order to correct the misunderstandings. For the developers, this means more work and therefore loss of valuable development time, while for customers it may mean higher costs.”



Even if they are usually short and can fit on a flash card, writing good user stories is no easy task. These are the five most common mistakes when formulating user stories.

1. Too broad in scope

User stories are often formulated too broadly. As a result, it can take a long time to implement them and features are implemented that were not needed in the first place. User stories should therefore be as small as possible: “Better several small user stories than one large one”, says Marković. “Smaller user stories focus on a specific aspect and are easier to assess. While this leads to dependencies in certain cases, it increases the flexibility of the product owner because secondary functionalities can be given a lower priority.

2. The problem is not accurately conveyed

If the development team does not understand the problem behind a user story, rather simply sees it as an attempt at a solution, this can make further software development harder. In the worst case scenario, developers come to an impasse because they have blocked other potential solutions. The focus when formulating user stories is therefore on the problem and not on the method for resolving it.

3. References to the requirements document

If user stories relate only to requirements documents, they are of little use to the development team. Marko Marković gives an example: “A user story that says that a web shop’s shopping cart should be implemented according to the 20-page section XY of the requirements document is not helpful because the exchange with the product owner can be completely lost.” The whole task is made more difficult if the requirements document changes during the development period. “This is like chasing after moving targets – which makes software development considerably more difficult.” The dialogue between the product owner and the development team is paramount in user stories, and not the requirements document.

4. Recording non-functional requirements

Software characteristics like security, usability, performance, etc. are general conditions for user stories. For example, if a user story states that the software should process all requests in five seconds, this can have a major impact on the architecture of the software. The entire software may have to be examined and optimised accordingly. “Non-functional requirements should therefore be understood as general conditions that apply to all user stories”, explains Marković. “It makes no sense to first implement a user story on a purely functional basis and to address all non-functional requirements, such as usability and performance, in a second user story.”

5. Specific solution paths

User stories describe a need – and not its precise implementation. They should be understood as a basis for discussion for the product owner and the development team. If the development team finds an elegant, efficient way to solve a problem, it must be able to propose this to the product owner. The team can exert much more influence on the product in this way as well as estimate outlays better and prioritise more easily. The likelihood that the software solution will ultimately be implemented in the manner desired by the customer is many times greater.

Writing user stories correctly

Various guidelines are now available that explain how to correctly formulate user stories. In general, however, they all recommend using the same formula each time:

As a <role>, I would like <goal/desire>, so that <benefit>.

“As a web shop customer, I would like to see a review of a product so that I can make a more informed purchase decision” would be an example of a good user story. The focus is on the problem – as well as on the potential benefit when this problem is solved. The goal is formulated precisely, but without suggesting specific solution alternatives. In discussion with the development team, the product owner decides whether a star rating, a grade rating, a discussion process or a different solution approach is best for the example mentioned – depending on how much effort is to be put into the feature.

“As a web shop customer, I would like to be able to manage my shopping cart” would, on the other hand, be an example of a bad user story. Not only is the specific benefit not expressed, the goal is also not clearly formulated. “The term manage can mean many different things here – e.g. creating, viewing, editing, emptying a shopping cart, etc.”, explains Marko Marković. “Such vague formulations should be avoided if possible.”

Paraphrasing in the sense of “As a web shop customer I would like to see a red exclamation mark to the left of the product description for products with a delivery time of more than five days so that I am informed of delayed deliveries” is also not suitable as a user story, because a specific solution path is prescribed. The development team is therefore too severely restricted and cannot suggest any further solutions to the product owner.