A User Story is a simple description of a feature. It is told from the end user’s point of view. That is to say, from the perspective of a person that needs a new product or service, or a part thereof. This is generally a customer (end customer). A User Story has the following simple structure:
- Who? What? And why?: As a (customer), I need a (description of what needs to be developed), so I can (answer the question why the product/service should be provided).
Individual User Stories are written on notes (such as Post-its). They are then posted on what is known as the Product Backlog. Here, the entire team can see each individual User Story. Overall purpose: this clearly shows the work to be completed, the amount of time it will take and the order in which the tasks should be performed.
The benefits of User Stories
One of the benefits of Agile User Stories is the ability to delve deep into the subject matter. A User Story is suitable for describing everything from a complete marketing project, to a specific component, such as a marketing event. A long User Story is also referred to as an ‘epic’. It can be subdivided into dozens of smaller user stories, so as not to lose sight of the big picture. The smaller User Stories go into detail regarding different aspects.
The management of a Marketing department would like to be able to show public holidays in their performance measurement tool. The idea is to enable analysis of results from marketing campaigns conducted for these holidays. The next step involves additional details, such as:
- This functionality must be available for the following holidays: Christmas, Easter, Mother’s Day, Father’s Day.
- I would like to be able to display a specific number of days before or after the holiday.
Details like these can be used to break a long User Story up into smaller ones. Next, these can be divided into tasks to be completed and entered into a Sprint Backlog.
The Product Owner is responsible for drafting a Product Backlog from the User Stories. This does not mean that only the Product Owner writes them. He or she may also delegate the drafting of User Stories to team members.
All participants should be aware that: It’s not about who writes a User Story or how it happens. Thorough discussion with both the Product Owner and the Scrum team is far more important. This is because every User Story is used to determine the tasks that must actually be completed to reach the objective.
When is a User Story written?
User Stories are written all throughout an Agile project. Therefore, it is a good idea to hold a story writing workshop at the start of the project. All team members should participate. The goal here is to draft a complete Product Backlog that thoroughly describes a sub-product. In many cases, at least the first two sprints are used for this. At this stage, some User Stories are epics. In a subsequent step, each User Story will be broken up into smaller, more manageable User Stories. The team also has the option to expand the Backlog with additional User Stories during the sprint.
Summary: User Stories are similar to traditional requirement documents. They describe the functionality of a new product or service to be developed. Every User Story serves as a starting point for discussions within the team. This helps to identify the actual tasks and corresponding time resources. These are entered into a Sprint Backlog.