“User Stories” are a very popular format to describe requirements. While it is not the only available format and by far not the only way to work, this format has many advantages, which make it so popular. Let us dive directly into it. The template for a User Story is this:
As a <role or persona>, I want <some goal> so that <some reason>.
For example: “As the call center agent of a ticketing service, I want to be able to quickly find information about the calling user so that I can correctly say his/her name and talk about his/her order history.”
This way of describing a requirement has many advantages:
- You need to think about who really has the requirement. This enables you development team to get into the user’s role, ask smart questions and make the right assumptions.
- You need to think about what your goal really is. This enables your development team to find efficient and creative solutions to your requirement.
- You need to think about why something is required. This enables you to evaluate how large the benefit of this feature would be and ultimately enables you to estimate the return on invest, which you can then use to prioritize your backlog.
Lets look at some examples
This sounds pretty reasonable and easy to do, right? In real life it is actually quite hard and takes a lot of practice and time to write meaningful User Stories. Let's use some examples to demonstrate what mistakes easily happen and how to improve the stories. We will use a hotel reservation website as example. Imagine this story:
As user I want to see a list of hotels (table view, title, address and images), so I can easily find the right information.
This fulfills our template and sounds good. The development team might start working on it. However it leaves some aspects open, which the development team will have to ask during the implementation or even make wrong assumptions:
- Are these the hotels that a tenant has rented before (my previous holidays), or the accommodations that the landlord owns? Who is the “user”, the tenant or the landlord? Both are different use cases, but because the “who” part was not precisely answered, it remains open. Rather use specific roles like “tenant” or “landlord”.
- Should the “list of hotels” be a card view, that would also work on mobile devices (as opposed to tables)? Could the team re-use the existing list of hotels that was already used in another place? Since the view is specified in much detail (“table view, title, address and images”), the development team would most likely not ask these questions. And because the “why” part is also open, the chances to make the right assumptions are quite low. Rather leave the “what” part more generic, so the team can find efficient solutions (like re-using things).
- How should the list be ordered? Is a search field needed? Since the reason for the list (why?) is not answered, the team cannot make the right assumptions. If we are talking about the hotels that a tenant has rented before, maybe an ordering by date makes sense. A search is not required, since there will not be more than five entries. If we are talking about the hotels that a landlord owns, the list might have 100 entries and an alphabetical ordering and a search might be required. Rather specify for which reason the feature is really needed.
An improved version might look like this:
As tenant I want to find the hotels I booked for previous holidays, so I can book them again and share the memories with my friends.
You can think this through with other examples:
As owner of the system I want to see a table with all customers, so I can see them all and analyse the data.
As accountant I want to find out which customers generate the most revenue, so that I can target them with specific marketing material, such as special newsletters.
As guest I want to see a red button next to the hotel, so that I can start the booking process with one click.
As potential tenant I want to find photos, description and price information about fitting hotels, so that I can make a decision whether this hotel really fits well for my next holidays.
Things to consider
Here are some things that might help you to get from “Basic” to “Improved” :)
- Think about the types of users who use your system. You can go the sophisticated way and write personas, or keep it simple and define some roles. Do not use generics like “user”, “developer”, “owner”.
- Really and honestly ask yourself why the feature is needed. Which goal does the user want to achieve when using this feature? Do not think in implementations (buttons, tables) but in goals instead.
- Be generic in the “what” part and give the development team some room for creativity. Do not specify details of the user experience or implementation unless they are really important to you for some reason.
I hope this helps you and motivates. It needs some practice but is really worth it. Well-written User Stories can easily save days and weeks of coding the wrong things :)
What are your experiences? I am looking forward to your responses and feedback!