What is a User Story?
A user story describes a small feature that one or two people can finish in two to five days. I like to describe a user story as a chunk – or chunklette – of value that a Scrum Team will deliver and demonstrate to the customer by the end of a Sprint.
History of User Stories
User stories were created by Kent Beck, the creator of Extreme Programming, as a simple way for customers and developers to chop up all the capabilities and functionality in a system so that it can be delivered in pieces. He recognized that customers and end users were much more efficient, engaged and relaxed when they told stories about what the system needed to do. This was in stark contrast to the standard approach to capturing system needs, requirements and priorities which emphasized documentation and formal sign-offs. He wondered if changing the dynamics of the requirements gathering process into something less formal and more casual, if he could get better results?
As a result of his curiosity, Kent developed a lightweight, flexible practice that enabled both parties to exchange shared understanding through story telling. More importantly, this story telling process was focused on the customer’s needs rather than the system’s needs. This change in perspective enabled the customers to drive software development in a direction that was most beneficial to them. This also freed up developers from attending unnecessary meetings and writing documents that no one would read. And since Extreme Programming emphasized the importance of doing the simplest possible thing that could work, the original user stories were written on index cards.
User Stories Today
User stories are used in almost all Agile software development teams as a replacement for a detailed product specification. However, user stories are not the product specification in a new format. User stories are a collection of words and pictures which describe how the business intends to serve the customer. They are simply a tool to develop shared understanding among members of a Scrum Team regarding the outcomes that matter to customers and end users. User stories are generally written in the language of the business and are prioritized according to the customer’s needs.
In practice, a user story is a placeholder to have a future, just-in-time conversation about a desired capability. That conversation is (re)started when the item is selected by the Product Owner. This means user stories are meant to be a dialogue between those who want the system and those who can build the system. The best user stories describe an intention a customer, or end user, is trying to achieve related to completing an important job, eliminating an extreme pain or realizing an essential goal. The 3C’s heuristic (updated here and here) exists to remind people to remain on focused on keeping your user stories lightweight, casual and fun.
How to Write a User Story
There is a lot of advice on how to write better user stories. A lot of what people think is “best practice” is bad advice because it emphasizes completing a template rather than understanding what outcomes the customer, or end user desires. To keep your user stories lightweight and simple, I recommend this simple framework to drive your conversations.
- Who: Who wants the feature? What role, user type or market segment has requested the feature? If you cannot identify the market segment or type of user that will use the feature, you are not ready to build it.
- What: What do they want? This is the easy part to identify and document. But avoid the trap of describing the story in technical terms. It is important that we write the story in the language of the customer or user in order to maintain our focus on the client and their needs
- Why: Why do they want it? What value will they receive from the feature? How will the feature improve the life of the user or the customer? What would be the consequence of NOT delivering the feature? If you cannot explain the value from the perspective of the customer or the users, you do not have a story. You have a technical task.
If you document these elements, plus the acceptance criteria, your users stories are going to be just fine.
