Do we really need user stories? After all, these are just the requirements written down in a fancy way, aren’t they? Though it’s easy to fall into the wrongful belief that user stories are just a statement of functionalities we want delivered, it’s also crucial to understand what they really are and how to write them successfully.
What are user stories?
User stories are a part of the agile approach and represent a small unit of work. User stories, as the name itself suggests, are user-centered: they focus on delivering value to the end-user instead of describing the details of functionalities. They’re written in non-technical language and usually consist of a few short sentences that provide the development team with context for their efforts.
Every user story should contain 3 elements:
As a
- type of user
I want to
- goal
So that
- reason
Let’s have a look at a very simple example:
As a registered user
I want to be able to change my password
So that I can keep my account secure.
As seen in the example above, a user story is a very simple way to present what value we expect to be delivered to the user with the given piece of work. An important thing to note here is that the “customer” or “user” doesn’t have to be an external customer.
Who writes user stories? Anyone can do that. It is the responsibility of the product owner to make sure that there are user stories in the backlog, but that doesn’t mean that it’s the product owner who writes them. Actually, over the course of development, every team member should create some of the user stories. It’s also important to remember that giving the team premade user stories is similar to providing them with a list of tasks to do. That’s not what you’re going for in an agile project. You want to discuss the functionalities and keep everyone equally involved.
Why do we need user stories?
Very often it’s easier for the team to visualize their work in order to keep track of what has been done, what’s being done, and what is yet to be done. Sometimes, user stories are written down on sticky notes and then arranged on walls or boards to facilitate planning. They can also be organized in a similar way in tools such as Taiga or Trello. Having to arrange the cards and plan development accordingly shifts the focus from writing about features to discussing them. User stories are used in agile methodologies: they’re burned down during a sprint, added to the backlog, and run through the team’s workflow. User stories are relatively easy to manage for the team, as they are small tasks that can be prioritized and managed to fit their workflow. As a user story is a small issue, the effect of it should be visible within a few days, which means that it should only take a few days to do it.
As mentioned above, user stories are small issues focusing on a particular goal. Combined, they make up a feature, and further, a bigger epic. An epic is usually too large for the team to complete in one iteration, so it’s broken down into multiple user stories that help organize the work. Given the size of these tasks, they also help the team estimate how much time they will spend on a task. It’s much easier to estimate a small part of the system than the development of an entire application. When user stories are written down, more detail is added and acceptance criteria are established. These criteria state what has to be done within the story so that the end result meets the customer’s expectations.
Read also: How good design can determine your product’s success
There are more benefits to user stories. Let’s have a look at some of the reasons why working with them is useful:
1. They keep the focus on the user
A list of user stories (rather than just to-do tasks) helps the team focus on solving the issues of real users and making the application useful and intuitive.
2. They encourage collaboration
The goal is defined, but the way to achieve it is not. This gives the team space to work together towards the goal and find their own best ways.
3. They encourage creativity in finding solutions
The tasks have to be done within one iteration, so the team has to be creative if they want to find the most efficient solutions in the right time.
4. They speed up the development
An end result of a story is delivered by the end of an iteration. Every piece delivered is a win for the team and this encourages them to keep up the work, giving them momentum.
5. They help organize work
As described above: smaller tasks are easier to manage and cross off the list.
How to write user stories?
It seems like an easy thing to do, right? You write who wants what and why. That’s all.
Well, in general, yes. But if you want to write a good user story that will facilitate the work of the team and bring you the right results, you have to make sure that your user stories contain the right details.
1. Specify your user
You need to know who your users or customers are and what they want. Carry out some user research beforehand, interview the users. Writing speculative stories that are based on some ideas will not bring you success.
2. Use personas
You can use personas to present your observations about the users. A persona is a fictional character, it’s usually given some name, relevant characteristics, and behaviors. Once you have them grouped, ask yourself what kind of goals your personas want to achieve. This will help you write user stories.
3. Keep the stories simple
User stories should only contain a few sentences. Make sure all the necessary elements are there: type of user, goal, and reason. Don’t write very complex sentences, avoid ambiguous phrases. Make sure that the development team knows what you mean.
4. Start with epics and break them down
As described earlier in this article, epics are bigger stories. They’re more general and difficult to deliver within one iteration. Break them down and refine them until you’re left with good quality small user stories. Determine a way to verify whether the story can be marked as done.
5. Establish acceptance criteria
Define what’s “done”. Write down the conditions that have to be fulfilled to mark the story as completed. This enriches the story, helps the team understand the details of a given story and make sure that you’ll be happy with the result.
6. Collaborate
Don’t rely solely on yourself while writing the stories. Over the course of development, every member of the team can add some user story. Brainstorm, discuss, keep everyone involved. This will help the team work fast and efficiently.
7. Make stories accessible
User stories are used to communicate the goals that are to be achieved. Put them on a wall or add them to a tool used by the entire team. Make sure that everyone has access to the stories and can work on them.
8. Care about time
Time is a difficult subject in software development. Bear in mind that stories should be completed in one sprint. Don’t expect the team to stretch the time in a week by writing complex stories, rather focus on making the tasks small enough. When you collaborate on the stories with the team, it’s easier to make the stories right.
