User Stories in Agile Project Management
Empowering Project Teams to Make Good, Customer Focused Decisions
The ability to work swiftly, adapt to rapid change, and liaise effectively with your customers are essential elements of product development.
In a process known as Agile Project Management, development teams work in short bursts called "sprints" to deliver working releases of a product or piece of software, in close collaboration with the customer or end user.
Putting yourself "in the shoes" of your user is key to the success of agile project management, as it allows you to see what is required, and the process for achieving it, from his or her viewpoint – and an effective way of doing this is to create "user stories." Essentially, these are brief, simple descriptions of what a user wants or needs to do, told from his perspective.
In this article, we explain how user stories are created and used, and we examine their advantages and disadvantages.
What Are User Stories?
User stories originated in the late 1990s, from the agile software development methodology Extreme Programming (XP).
They give you a simple way of defining what the customer wants to achieve with a particular piece of functionality. She collaborates closely with the development team to create a user story, and they are written from her perspective, not the developers'. They help everyone understand the who, what and why of a project.
User stories empower developers and engineers to use their experience and creativity to deliver the best possible, user-focused solution to a problem, rather than constraining them to deliver a detailed design that could have been drawn up by someone with less engineering experience. This helps to get the very best from your engineers, and to give them much greater job satisfaction. It's a more democratic, respectful way of working than the traditional "command and control" approach to project management.
User stories are associated most commonly with software development, but they may also be appropriate for other kinds of project teams, such as customer service or finance.
Agile expert Mike Cohn, author of the 2004 book, "User Stories Applied: For Agile Software Development," suggests that user stories should follow this basic template:
As a [type of user]
For example, say you want a website for your garden furniture store. You would discuss your requirements with a developer, and your user story description might be, "As a buyer, I want to be able to add multiple items to my basket, so that I can save time."
The description is not the whole user story. It's a "conversation starter" that is then discussed by the development team at a scrum meeting. Scrums encourage collaboration and alert everyone to issues, such as changing customer demands.
User stories are usually written on index cards or sticky notes, then arranged on a board so that everyone in the team can see and discuss them. (If your team members work remotely, you can use software such as Jira® or Trello™ to document and share stories.)
User stories are not to be confused with "use cases." Like user stories, use cases describe interactions between the project and the user. But where user stories are small and concise descriptions from the customer's perspective, use cases have a much larger scope and are focused on the work's detail and implementation, rather than its outcome or goal.
How to Create User Stories
In 2001, Ron Jeffries, one of the co-founders of XP, outlined the components of a user story with his "three Cs" model, which stands for Card, Conversation and Confirmation:
Card. The customer and the product development team agree on a user story, and this is written on an index card. The description has just enough information to identify the project's requirements.
Software consultant Bill Wake developed the INVEST guidelines to create good stories:
- Independent: the user story should be self-contained and different from other user stories, so that you can schedule and implement them in any order.
- Negotiable: user stories can be rewritten or negotiated during development. They should capture the main ideas, and additional details can be discussed with the customer.
- Valuable: a user story must focus on its value to the customer.
- Estimable: a good user story will provide enough of an estimate in size and scope to enable the customer to plan and schedule the product's final delivery.
- Small: user stories should be small enough to represent no more than a few weeks' worth of work. If a story requires a month or more of work, its scope may be too broad, and it may need to be broken down into smaller stories.
- Testable: the user story must provide enough information to make test development possible.
Conversation. It's important that the development team and the customer continue to share thoughts and ideas that arise during the development process. Any additional details, such as an expansion of the description, are then added to the card.
Developers also require clear "acceptance criteria" to be written on the card. These are the conditions that a product must satisfy to be accepted by the customer. Using our previous example, the acceptance criteria for a buyer using the garden furniture website might be, "Payment can be made by credit cards x, y and z."
The acceptance criteria mean that there are testable items, which can help the test team to build acceptance tests for engineers to develop against.
It can be useful to look at personas in user stories. It's better to generate stories for a specific user type rather than a generic "as a user." For example, your end user might be an L&D manager, career changer, or occasional user. You can "flesh them out" with details such as their goals and likely day-to-day problems.
Confirmation. The final chapter of the user story is the customer's confirmation that it has been delivered and implemented successfully. The project can be signed off once the customer is satisfied that the acceptance criteria have been met, and the team's "definition of done" has been met.
A user story that includes a lot of functions and detail is called an "epic." These large stories are usually broken down into several smaller user stories, which can each be fitted into one sprint. A set of stories that relate to one another is a "theme."
Advantages and Disadvantages of User Stories
User stories offer a flexible, collaborative approach to project management that empowers the team members, respects their experience, and results in a much better delivery to end users. (To see a classic illustration of why user stories are so useful, click here.) They also offer numerous other benefits:
- They are easy for customers without much development experience to write and understand.
- A brief user story written on a card encourages the project team to discuss and focus on ideas, rather than get bogged down in unnecessary detail.
- They offer a quick way of identifying customer needs and responding to them, and the information in them is made available to everyone involved in the project.
- The emphasis on regular discussions and conversation means that the chances of misinterpretation and confusion are reduced.
When they are well-formed, user stories are very effective and have few drawbacks. One limitation is that customers sometimes misunderstand the concept. They can make the assumption that the user story is just the initial description. A user story is not complete without the additional details that arise from discussions, and the acceptance criteria.
Also, given the collaborative and negotiable nature of the process, it's harder to predict a completion date for a complex project based around user stories.
User stories are short, simple descriptions of features of a project, product or system told from the perspective of the user or customer. They usually follow a simple template (As a
Ron Jeffries created the three Cs system of creating user stories – Card, Conversation and Confirmation. Once the story is written on the card, using information about the customer's requirements, the team discusses the story with the customer to ensure it's on the right track. At this stage, team members add acceptance criteria to the back of the cards. Finally, the story is confirmed with the customer with an acceptance test, and the project is delivered.