Undoubtedly, many of you have come across the concept of user stories mentioned in Agile or Scrum. At times, it can almost feel like pretty much everything in Agile software development, project management and other activities revolve around user stories. The weird thing is that while they are not mentioned anywhere in any “official” agile or Scrum guidelines, that's not entirely untrue.
User stories are, for better or worse, an integral part of agile for the majority of people.
In this guide, we will go over user stories in great detail, explain what they are and what their purpose is, as well as how they are created and used in sprints. We might even touch upon the whole heated debate on whether they are good or bad for Agile teams.
What exactly are user stories?
Simply put, user stories are short descriptions of what the users of a piece of software want (or are expected to want) to be able to do with it. As you may already know, Agile methodology focuses on iterative delivery of valuable working software by getting stakeholders involved in the process of development. Therefore, user stories basically represent the consumer needs and what they want in a product.
The most commonly used user story template goes like this: "As a (type of user) I want (some goal) so that (some purpose or reason)."
These short descriptions are usually written on a piece of paper or sticky notes and they are arranged on whiteboards or walls in the offices. Alternatively, they can be created in project management tools for Agile teams.
One of the advantages of user stories is that they can vary in detail. You can write a story that encompasses a wide range of functionalities, which is referred to as an epic in Agile. Epics need to be broken down to many smaller user stories so that they can be worked on in small iterations. As the team gets closer to actually working on them, the user stories get more and more granulated and new information is unearthed, guiding the work.
This is actually the purpose of user stories. They are designed to aid in planning and discussions. In other words, discussing product features and how to implement them is more important than what's actually written down.
Who writes user stories and when?
Pretty much anyone can write down user stories, ranging from team members to external stakeholders. In Scrum, the Product Owner is responsible for creating and refining the Product Backlog (which contains User Stories) but that doesn't mean they are the ones who write them.
Okay, but when are user stories written? User stories are written throughout the entire project's lifecycle. They represent changes that are more than welcome in Agile practices. That's why they can be added anytime during the project.
User story templates
Now that we have defined what user stories actually are, let's go over how they are being written in more detail.
First, let’s remind ourselves of the user story template we mentioned earlier:
This time, let’s go a bit deeper.
- As a (persona or user) - For whom is this feature designed? The designated user who will use a product in the future. We must also determine their intent, as well as the value they'll gain from this feature. This is achieved by creating buying personas or by interviewing intended users and asking them the right questions about the product itself. Therefore, who is this person we're building a feature for? Are they a manager, student, desk clerk or admin? How does this person think, what do they feel and how do they work? These are the questions to ask when defining a user or a persona for the story.
- Want (some goal) - What is the user intent? What is the user trying to achieve? In other words, we are describing the end goal of the user not aspects of the feature itself. That being said, we should be focused on how to help the user intent, i.e., achieve their goal, instead of focusing on how they'll use a feature.
- So that (benefit, purpose, reason) - Here we define the potential problem that requires to be solved so that the user can actually benefit from the feature we've implemented. In other words, how does the user's immediate desire to achieve something fit into a bigger picture? How will we deliver value to the user and if the solution we provide will actually solve a problem is what needs to be defined here.
Now that we have broken down how user stories are created, let's clear things up a bit by giving a few examples.
Examples of epics
- As a project manager, I want to be able to create project roadmaps so that I can plan a project in advance.
- As a sales department, we want to integrate our sales channels so that we can increase chances of increasing revenue.
As you can see, epics are too large and/or complex to be developed in a single iteration. They are a good starting point for conversations on where to start and how to deliver value to the customer as soon as possible.
User story examples
- As a Scrum Master, I want to have a 100% overview of a Scrum Board in my tool so that I can understand who will work on what on any given day.
- As a shopper, I want to be able to put in my credit card details so that I can pay for the product.
- As an HR manager, I want to see a list of candidates so that I can invite them for interviews.
- As a blogger, I want to be able to edit existing articles so that I can update information in them.
The INVEST approach to user stories
In order for user stories to be meaningful, they have to be created and written properly. After all, the functionalities that originate from users stories must be valuable to end-users. We may have emphasized the importance of user stories and their quality a couple of times, but now we will delve a bit deeper into making that quality a reality. That's where the INVEST approach comes into play.
- Independent - User stories need to be as independent as possible. In other words, they technically need to be "order independent", which means you can work through them in any order you wish. You may be wondering why that is relevant. The main reason is that the independence of user stories allows for efficient backlog prioritization.
- Negotiable - As mentioned before, user stories are designed to facilitate discussions, which means they're not set in stone. User stories encompass what the user desires. The resulting functionality needs to be an outcome of a collaborative process between customers, developers, testers and any other stakeholders. This increases the likelihood of developing features and functionalities that will work as expected and meet the needs of end users.
- Valuable - Every user story needs to have a recognizable value. However, when you look at the bigger picture which entails both the users or customers and the organization that develops the software, then users stories must be prioritized in the backlog in accordance with business values as well. The main reason is that business value includes user value, as well as the internal value to the organization itself. Therefore, completing the story should provide value to everyone equally.
- Estimable - In order to properly prioritize the user story, you need to be able to estimate or size it. A user story with high value but lengthily development time may not reach the top of the prioritization list, mainly because it would take too long to develop it. It may resemble more of an epic than a user story in that case. You can always gain more clarity by splitting it up into smaller stories. However, sometimes that's not enough, which means you'll need to research the story a bit more. Just make sure you time-box the research so that it doesn't take out valuable time and deny the product of something else that could've been completed more quickly instead.
- Small - User stories represent small workload teams can take on for each sprint. But how small they should be? That depends on the organization that develops the software and the teams, as well as the product itself. In general, for a two-week iteration, user stories should average on three to four days of work to get the stories to the "done" state. That way, they'll remain, in fact, small.
- Testable - In agile, testing is conducted alongside development and QA has more involvement and responsibilities than with traditional methodology. That being said, user stories must be testable so they can reach the "done" state. In other words, acceptance criteria should be written immediately for each user story. This enables acceptance-test driven development, which fosters more collaboration and quality.
As you can see, by investing in user stories you can ensure that they are designed with value in mind and that the functionalities that come out of user stories will actually be beneficial to everyone.
Technical user stories
When building any kind of software, not all aspects of the product are user-oriented. In other words, the team will do work that will not directly solve specific users’ need. Refactoring work and back-end stuff usually fall into this category. This kind of work may result in more comfortable user experience, but the users will probably never be aware of it.
For a couple of reasons, this can cause confusion within the team which tends to result in some very clumsy and unfortunate “technical user stories”.
The first reason is that some teams either consciously or unconsciously equate with Product Backlog items and feel like every bit of work has to be expressed in the form of a user story. Often times, such teams have been poorly coached and/or are forced to follow such a practice.
Another reason is that some teams will forget that user stories explain problems and not solutions (once again, with a hint of PBI = User Story confusion).
In such situations, teams may come up with “user” stories that start with something like As a developer/ As a SysAdmin/As a Product Owner/ As an API
It is quite obvious from such openings that such “user” stories miss the point.
In such cases, it is perfectly okay to not express the work that will be done in the form of user stories. It will still be work that may be necessary for user stories to be delivered, but there is no good reason to cram it into technical user stories.
Mike Cohn, for example, suggests looking to Feature-Driven Development for guidance, with its own syntax for system features than having to rely on "As a (user)". Here's an example:
- FDD uses this format for writing cases: (action) the (result) (by/for/of/to) a(n) (object)
- As an example: Enable automatic data backups to avoid losing data.
User story mapping
A big part of the Agile approach is continuous improvement. If there's room for a system or a process or even a method to be improved for the better, then, by all means, go for it.
One such innovative idea is user story mapping.
Unfortunate arrangement of the backlog can potentially cause Agile teams to lose perspective or neglect the big picture of what the entire product is supposed to do. It becomes difficult to explain to others what the product is all about and what it's supposed to do, especially when the team is mainly focused on incrementally developing working bits of software based on user stories. Sometimes, the backbone of the product becomes obscured as new features are discussed and developed.
User story mapping has the potential to remedy these issues and allow teams not to lose sight of the end-goal.
User story mapping upgrades the backlog from a list of user stories into a more visual “map” that can take any form the team will find most intuitive. The story map is a representation that conveys the hierarchy and the relationships between different stories and how they add to the product. This way, the big picture overview is never neglected and can be updated easily if need be.
This approach also provides visibility of the product’s priority features and functionalities. In other words, it helps establish which parts of the product are essential and provide immediate value for the customer. As a result, this kind of a story map best supports the true agile approach where value is delivered continuously.
User stories are important in agile product development for the simple reason that they reinforce many of the main ideas behind this approach. They help teams focus on what matters to users, they encourage discussions about the product and they help the team stay the course even as new information is unearthed and the product evolves.