What is a User Story, how is it formulated, what examples exist and how important are acceptance criteria?
User Story Definition
A User Story literally describes a story of a user. In agile project management and software development, a User Story is a tool to describe the desired functionalities of a system from the user’s point of view. A User Story offers three main advantages:
- it is easy to understand and conveys the wishes of the user
- it is quickly created and facilitates the estimation of the effort required for its realisation
- it can be detailed step by step and thus supports iterative development
As a concept, the User Story goes back to Extreme Programming (XP) – and not to the Scrum Guide as is often assumed. Extreme Programming is an agile development model developed between 1995 and 2000 in a Chrysler project by Kent Beck, Ward Cunningham and Ron Jeffries.
Tips for Writing a User Story
In contrast to a story you tell around a campfire, a User Story should be described in short sentences and simple words. This will ensure that all colleagues involved in your development understand it without any technical background. It’s all about who, what and why, i.e. who wants what from a system in order to benefit from it. How the desired functionality is implemented later is irrelevant for a User Story. The following sentence structure is recommended when writing a User Story:
As a (role) I want (goal) so that (benefit).
When formulating the story, make sure you write it from the user’s or customer’s point of view and create a real benefit for them.
User Story Examples
- As a movie fan, I would like to be informed about new movies in order to know which movies will be shown next.
- As a movie fan, I would like to receive a newsletter once a week to know which movies will be shown next.
- As a movie fan, I would like to be informed once a week by email about new science fiction movies running in the Colosseum cinema, in order to be able to book tickets online for this cinema.
Even with the recommended sentence structure, user stories can vary in detail. You can understand them relatively roughly and gradually with additional details, until they are detailed enough to implement them.
Alternative User Story Setting Templates
User Stories are written by or for users or customers to influence the functionality of the system to be developed. Besides the most commonly used sentence template “As (role) I want (goal) so that (benefit)”. there are still some alternatives:
“In order to (receive benefit) as a (role), I can (goal/desire).”
This template goes back to Chris Matts, an English programmer and expert in the context of Agile and Lean Management, who puts value and benefit before functionality.
“As (who) (when) (where), I (want) because (why).”
This phrase is based on typical W questions: who, when, where, what and why.
“As (user role), I can (what) so that (why).”
This formulation goes back to Rachel Davies, an agile expert.
“As (persona), I want (what) so that (why).”
This wording goes back to Roman Pichler, a product management expert.
Irrespective of the subtle differences, it is advisable to opt for an alternative and retain the typesetting template. This facilitates the formulation of user stories and promotes understanding.
User Story Estimating Effort
How do you estimate the effort of a User Story? The answer is: in person days or with story points. When working with story points, the development team determines a criterion or a combination of several criteria to determine the size of the User Story. Such a criterion could be complexity, e.g. in relation to the use of different layers of the architectural model. Story points are therefore not about the time required to implement the User Story, but about the structural properties of a User Story. Of course, an experienced development team can implement larger user stories in a sprint than a less experienced team, but the size of the story remains unaffected. In other words, the characteristics of a User Story do not depend on the skills of the team.
In Scrum, the so-called velocity expresses how many story points a team implements per iteration, so that even when working with story points, statements can be made about the iteration in which a feature is delivered. In practice, features of a User Story can often be identified without detailed activity analysis. This is an essential difference to the effort estimation in person days, where all necessary activities are identified and summed up. Often a User Story of medium size is selected as reference and the estimation is performed in comparison to this reference. The value range is a Fibonacci series up to 13, supplemented with 20, 40 and 100, where 1 corresponds to a task of low complexity and 100 to a task that cannot yet be estimated.
User Story Splitting
Before a sprint can begin, the selected user stories must be small enough to be realised within the sprint. User Story splitting is therefore an important task. It should be based on the user’s benefit (“As [role] I want [goal] so that [benefit]”) and not on the technology. Ideally, it should not be carried out by one product owner alone, but by the entire team – at least with several team members. This avoids unnecessary dependencies between user stories, the early description of solutions and the excessive production of spike stories.
User Story Acceptance Criteria
When do you know if a User Story has been fully implemented? Acceptance criteria help here. You use acceptance criteria to define results that have to be fulfilled by the user story.
Acceptance criteria act as a link between User Stories and test cases. One way to define acceptance criteria is to question keywords, i.e. verbs, adjectives and nouns. Example:
“As a visitor to the cinema, I would like to save my purchased tickets in my profile, so that I can see which films I have seen.”
- Who saves what, when and where?
- What happens when a new ticket is saved with already saved information?
- How many tickets should be saved?
With such questions you can easily find acceptance criteria. As a checklist they are a good basis for the development of extensive test cases.
INVEST Principle of William Wake
How do you determine whether you have defined a top-quality User Story? With his INVEST principle, William Wake offers help in formulating User Stories. INVEST is an acronym:
- Indepentent: The User Story stands for itself and is independent of other stories.
- Negotiable: The content of a story is negotiable and is described in more detail bit by bit until it can be implemented.
- Valuable: The user story is valuable and offers the user or customer added value or benefits.
- Estimable: The effort of the story must be estimated by the developers.
- Small: The User Story is so small that it can be realised within an iteration or sprint.
- Testable: The story has acceptance criteria and can be tested.
Dependencies between User Stories
User Stories should – as the INVEST principle demands – be independent of each other. In practice, however, with regard to the implementation of User Stories, there are in terms of
- content or subject matter,
- temporal or
- normative or regulatory dependencies.
Indirectly, different competencies of individual team members can also lead to dependencies in the realisation of User Stories. Even if a team works as a whole, individual employees often have more competences than others in certain areas and the transfer of these competences does not always work as easily as teams would often wish.
User Story Mapping is best suited for visualising dependencies. Alternatively, dependencies can also be documented in separate tables or as a supplementary note in the User Story.
Download the User Story Whitepaper for free now.
Everything important about User Stories and User Story Mapping at a glance.
- What is a user story and how can it be formulated?
- What are the differences between user stories and use cases, features, specifications, etc.?
- What is user story mapping and what are its advantages?
- How can the effort of a user story be estimated and what is the INVEST principle?
- What are the acceptance criteria of a user story?
Knowledge on 10 pages to take away.
User Stories vs. Epics or Features
The different scope of a system’s functionalities and benefits from a user’s point of view often leads to the categories Epic, Feature and User Story. However, the differentiation between these three categories is not standardised, i.e. in some companies features are more comprehensive than Epics. Therefore, it is important that there is a common understanding within the company. The distinction between Epics, features and user stories could be as follows:
Epics describe functionalities at the highest professional level.
Features refine the functionality of Epics and can be used for release planning. However, they are still too extensive to be implemented in an iteration or sprint.
User Stories refine features and can be planned and implemented in sprints.
User Stories vs. Use Cases
With a use case, you describe how an actor interacts with a system to be developed. Use cases are very popular because, like user stories, they enable the collection of requirements for a system. And both pursue the goal of creating added value for the user. But what are the differences between use cases and user stories? A use case is larger and more detailed than a User Story. It covers a context and is therefore more comprehensive. It therefore includes several user stories. And it is much more durable, i.e. it is maintained throughout the entire system development, while the User Story practically disappears in a sprint.
Use cases and user stories complement each other very well. By combining both methods, requirements can be understood more precisely. To include use cases like user stories in a sprint plan, you have to cut them into use cases slices. This technique is called Use Case 2.0.
User Stories vs. Customer Specifications
In a customer specification, a customer describes his requirements for a system to be developed. The system requirements end up in the customer requirement specification, while the project requirements such as budgets, schedules, milestones, etc. are recorded in the project order or, if necessary, in a project manual. A requirement specification has a different function than a customer specification, because in it the requirements from the customer specification are clarified and detailed. The requirement specification can be in the classic form of a “System Requirements Specification” or in an agile environment with epics, features and user stories. It can therefore be understood as a product backlog.
It can happen that requirement specifications written by software developers are difficult to understand for specialist departments. Such communication problems are addressed with agile methods such as Scrum. In Scrum, the product owner has the task of generating as many requirements from the epics, features and user stories as can be realised in the next sprint. In contrast to the drafting of a customer specification, the lead time for planning and realisation is reduced and the content flexibility is increased. This approach is very pragmatic, but it also places demands on other levels such as contract design, cost estimation and performance accounting.
Technical Stories and Spike Stories
In addition to User Stories, development teams often also use so-called technical stories. They do not describe functionalities or a user’s benefit, but criteria that record the technical effort behind a user story. Development teams try to define non-functional requirements such as performance, scaling, security or availability. It is important that there is a clear separation between technical stories and user stories. By marking them accordingly, you avoid misunderstandings during prioritisation and sprint planning, e.g. as part of a user story mapping.
A spike story is a type of user story that is used to better understand a functional or technical requirement and thus eliminate uncertainties. It is an order for an analysis to answer a question, gather information or address project risks. Unlike a user story, it is not estimated. The development team is committed to investing a certain amount of time to perform the necessary analysis. The result leads to a revision of the user story in the sense of refinement, a division into several user stories or the description of a completely new user story.