What is a User Story?
Table of Contents: Definition – Writing tips – Alternative sentence templates – Differentiating terms – Questions from the field – Download – Notes
User story definition
A user story is a tool to describe a desired functionality of a system from the user’s point of view. The term comes from the English language, where user means user and story means story. In the literal sense, a User Story describes the history of a user.
Often used in agile project management and software development, the user story has three main advantages:
- it is easy to understand and conveys the user’s wishes and benefits,
- it is quickly created and facilitates the estimation of the effort required to realise it, and
- 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, as often assumed, to the Scrum Guide. Extreme Programming is an agile development model that was developed in the mid-1990s in a project at Chrysler by Kent Beck, Ward Cunningham and Ron Jeffries.1
Tips for writing a user Story
Unlike a story told around a campfire, a user story should be described in short sentences and simple words. This way you make sure that all colleagues involved in your development understand it even without a technical background. Above all, it is about
- WHO,
- WHAT and
- WHY,
i.e. who wants what from a system in order to get what benefit from it. How the desired functionality is later implemented is irrelevant for the description. When writing, the following sentence template is often used:
As a (role) I want (goal) so that (benefit).
Here you can find some examples:
- As a film lover, I would like to be informed about new films so that I know which films will be shown next in the cinema.
- As a film lover, I would like to receive a newsletter once a week to know which films are showing next in the cinema.
- As a film lover, I would like to be informed once a week by e-mail about new science fiction films playing at the Colosseum cinema in Berlin, so that I can book tickets online for corresponding films in this cinema.
Even with the recommended sentence structure, descriptions can vary in detail. An initial user story can be formulated relatively roughly before it gradually becomes more detailed in the course of refinement until, in the end, those involved understand why it is specifically possible and where exactly the benefit lies.
Alternative user story setting templates
Besides the widely used sentence template “As (role), I want (functionality) to achieve (benefit).” there are still some alternatives2:
“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 (user role), I can (what) so that (why).”
This formulation goes back to Rachel Davies, an agile expert.
“As (who) (when) (where), I (want) because (why).”
This phrase is based on typical W questions: who, when, where, what and why.
“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.
Differentiating terms: user Stories and other tools
The different scope of a system’s functionalities and benefits from a user’s point of view often leads to the categorisations epics, feature and user story. However, the distinction between these three categories is not standardised, i.e. in some companies features are more extensive than epics, for example. It is therefore important that there is a uniform understanding within the company. The distinction could look as follows:
Epics describe functionalities at the highest technical level.
Features refine the functionalities 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.
And what is the difference to a use case, which also describes how an actor interacts with a system under development? A use case covers a context and is therefore more comprehensive. It therefore covers several User Storys and is much more durable, i.e. it is maintained throughout the entire system development, whereas the user story practically disappears with its implementation in a sprint.
Both approaches complement each other very well in development practice. By combining both methods, requirements can be understood more precisely. In order to include use cases in a sprint planning, they have to be cut up into use case slices. This technique is called Use Case 2.0.
What are the differences to technical stories? Development teams often use technical stories. They are not used to describe functionalities or a user’s benefit, but criteria that capture the technical effort behind a user story. In this way, development teams try to define non-functional requirements, for example, in terms of performance, scaling, security or availability. When recording, it is important that there is a clear separation of the two types. By marking them accordingly, you avoid misunderstandings during prioritisation and sprint planning, e.g. in the context of mapping.
And what is the difference to a spike story? A spike story is used to better understand a functional or technical requirement and to eliminate uncertainties. It is an assignment for an analysis that answers a question, gathers information or addresses project risks. Its effort is not estimated. The development team commits to invest a certain amount of time to perform the necessary analysis. The result leads to a refinement of the description, a splitting into smaller units or the formulation of an entirely new user story.
Questions from the field
Here you will find some questions and answers from the field:
What is the INVEST principle and how does it help with the formulation of user stories?
How do you know if you have defined a good quality user story? William Wake offers good guidance for formulation with the help of the INVEST principle.
INVEST is an acronym:
- Independent: The user story stands for itself and is independent of other stories.
- Negotiable: The content is negotiable and is gradually described in more detail until it can be implemented.
- Valuable: It is valuable and offers the user or customer an added value or benefit.
- Estimable: The effort to realise it must be estimable by the developers.
- Small: It is so small that it can be realised within one iteration or sprint.
- Testable: It has acceptance criteria and can be tested.
Here you will find information on the strengths and weaknesses of the INVEST principle.
How does the effort estimation for the realisation of a user story work?
User stories are often estimated in person days or by means of so-called story points. When working with story points, the development team determines a criterion or a combination of several criteria to define the size of a story. One such criterion could be complexity, for example in relation to the use of different layers of the architecture model. In other words, it is not about the time needed for implementation, but about structural properties. Of course, an experienced development team can implement larger items in a sprint compared to a less experienced team, but the size of the story remains unaffected. In other words, the properties 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 in which iteration a feature will be delivered.3 In practice, characteristics 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 a reference and the estimation is carried out in comparison to this reference. The range of values is a Fibonacci series up to 13, supplemented with 20, 40 and 100, where 1 corresponds to a task with low complexity and 100 to a task that cannot yet be estimated.
What is user story splitting?
Before a sprint can begin, the selected user stories must be small enough to be realised within the sprint. In order to achieve this, individual stories are broken down, the common term for this is user story splitting. The splitting should always be based on the user’s benefit and not on the technology.
Ideally, it is not carried out by a product owner alone, but by the entire team – or at least with several team members. This avoids unnecessary dependencies between individual items, the early description of solution approaches and the excessive production of spike stories.
What is the importance of acceptance criteria for user stories?
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.
How can dependencies between user stories be visualised?
User stories should – as the INVEST principle demands – be independent of each other. In practice, however, with regard to the implementation, there are again and again
- content-related or professional,
- technical
- 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.
How does DEEP help with the management of user stories?
User stories are managed in backlogs. This is where the acronym DEEP comes into play, which Roman Pichler explains in his book “Agile Product Management with Scrum”4:
- Detailed Appropriately: User stories that are to be implemented soon must be more detailed than those that are to be implemented at a later point.
- Estimated: Backlog items are estimated, with higher priority items being estimated in more detail first than lower priority items.
- Emergent: New information and knowledge is gained in the course of development. Corresponding items are consequently added, removed or reordered in the product backlog.
- Prioritised: All items are prioritised in the backlog. The goal is to implement the most important ones first.
DEEP is considered an useful concept that emphasises continuous work with backlog items.
Download the User Story Whitepaper for free now.
Everything important about user stories inclusive mapping at a glance.
- Definition and sentence templates
- How does mapping work and what advantages does it offer?
- Differentiation from other tools
Knowledge on 10 pages to take away.
How important is it in practice that a user actually formulates his or her story, rather than a surrogate trying to take on the user’s perspective?
Notes:
[1] In the course of this, the 3 C’s were also introduced: Cards, Conversation and Confirmation. User stories are written on cards. A card forms the basis for a conversation. And confirmation means the acceptance criteria that must be met and tested to ensure that the desired functionality is delivered correctly.
[2] There is a sentence template that helps address technical debt: “If we don’t do this <action>, it will cause <impact> and that will result in <damage>.” Sometimes this form of description is called a negative user story.
[3] The Scrum Guide does not mention velocity, user stories, story points or acceptance criteria. Nonetheless, these tools are used in many organisations.
[4] Agile Product Development with Scrum
Here you can find a podcast on the topic: User Stories. More than just a template.
If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.
And here you will find additional information from our t2informatik Blog:
Boost your backlog – Part 1
User stories – when the harm is greater than the benefit
Eliminating dependencies in Scrum