User Stories: A Quick Guide

Posted by

In 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.

Below I explain how user stories are created and used, and then 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. The customer or end user collaborates closely with the development team to create a user story, and they are written from their perspective, not the developers’.

It’s also 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.

User stories usually follow this basic template:

As a [type of user], I want [some goal] so that [some reason].

For example, say you want a web 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.” This is 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. (see ‘Introduction to Kanban boards’ here)

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 web store might be, “Payment can be made by credit cards x, y and z.”

Note:
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.

Note:
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. 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.

Your feedback is most welcome, please leave a reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.