In an earlier blog post I described how I apply user story mapping in release planning. In this post I want to go back to the beginning, or at least far enough back to explain what I think makes a good user story. But let’s start at the beginning – what is a user story anyway?
By definition a user story is a (software) requirement formulated in everyday language. It can represent a user’s need, serve as a planning item in agile software development, or simply be used as a basis for discussion. User stories are understandable for everyone and clearly express the customers’ benefit.
User stories should not be confused with use cases. Use cases originate from classical software development, and represent requirements expressed in natural language in the context of users. The key difference is that use cases represent all success and failure scenarios within the scope of the relevant technical problem. The use case thus forms an entire framework, and contains several scenarios that fit a particular technical requirement. A user story, on the other hand, describes a concrete scenario.
But how should a user story be structured, and what should you look for when creating one?
User stories are basically written from the users’ viewpoint, and capture the ‘who’, ‘what’ and ‘why’ of a requirement. First of all, a story needs a title that should succinctly summarize what it’s about: for example, ‘Different Delivery Address’. A description should be added – you could use the following template:
As a <role> I want <target / wish>, <benefit>.
An example might be ‘As a customer of an online shop I want to be able to specify a different delivery address, so that I can send a gift to anyone’.
You can add further information after the description, such as acceptance criteria, specifications and wireframes. Acceptance criteria are particularly important, because they tell the developers when the user story is completed, and the steps necessary to achieve it. A user story should be short and concise, so that its contents can fit on an index card.
A finished user story can then be integrated into the product backlog and prioritized.
INVEST is an acronym that was developed originally for agile software projects by Bill Wake. It serves as a structure that helps to ensure the quality of the elements of a product backlog. User stories are a common way to develop product backlog elements.
Ideally every user story should be written according to the INVEST principle:
|
I (Independent) |
The story does not depend on any other user story. |
|
N (Negotiable) |
The story serves as a basis for discussion and can be developed further together. |
|
V (Valuable) |
The story always elaborates an advantage for the user, customer or client. |
|
E (Estimatable) |
The story is quantifiable: it has enough concrete detail to enable an experienced team to appreciate its scope. |
|
S (Small) |
The story is the right size. |
|
T (Testable) |
The story contains enough information to allow it to be tested. |
In addition to the INVEST structure, in my previous projects I accumulated more tips for creating a good user story:
Asking yourself following questions can help ensure that a user story is sound:
All these tips have helped me write good user stories in my previous projects, stories with which the entire development team could work, while at the same time making the requirements and problem solutions visible to the customer. Nevertheless, good user stories are not written by themselves – they take a lot of practice.
In my next blog post I will tell you about splitting user stories correctly. It’s not always easy to find the right size for a story, but here too there are techniques that can make your job easier. Until then, try writing user stories and using them in release planning. To support you, you can download our free matching template.