Using User Stories to Document Requirements

User stories are a way to describe the requirements at a level of detail that fits perfectly in a sprint backlog, but also in the Product Backlog. When it comes to requirements for the next 1-3 sprints, they are often expressed in the form of user stories.

User Stories Template:

A user story template typically consists of the following three parts:

Example: As a test manager, I want to see the status of the requirements so that I can plan testing.

Example: As a train passenger, I want to see the departures available so that I can choose what time I want to go.

Who, what, why?

Who will make use of this functionality?

Keep in mind the user personas, their varying roles and access levels to the software. If the product owner performs tasks in the system, choose the role the PO has in that context, such as administrators, editor or web master.

What should a user be able to do/accomplish?

Do not specify in too much details. The format of the user story helps you writing shorter requirements. If you specify too much details, you risk that the team sticks with this as the best solution. Avoid technical words like cookies and database. Use words that the user would use, for example, “I want to remember my login detail” instead of “I want a cookie.”

Why should the person do this?

This is the goal and it should be written by the product owner, since it will be based on the value of the feature. The why-part of the user story is useful for the team to get a deeper understanding of the requirement. If you omit it, developers and testers need to guess, and that will lead to confusion and misunderstandings.

Tips for working with user stories

Use the principle “just in time, just enough”.

• Don’t write too many details and don’t write the stories too early. Write them when they are needed and sick to the template. Discuss and formulate the stories together with the team. Write user stories for 1-2 sprints ahead. This makes you plan an enough time frame.
• It is better to write small user stories than large. Divide and conquer. This makes it possible to deliver functionality is faster in shorter cycles. This in turn leads to more feedback and the result is higher quality. Divide larger user stories into smaller. This is not that trivial, it requires some training to get it good.
• Define what the minimum amount of critical requirements is. Focus on the most important stuff early and postpone less important functionality (this is called defer commitment and is one of the principles from XP, extreme programming).
• Improve functionality incrementally. In the first iteration you can create and delete features. In the following sprints you can add the “change” features. When working agile, you strive for delivering high-quality slices of the software iteratively, rather than complete feature sets at once.

Compare with the Mona Lisa. Leonardo da Vinci started with a sketch and ended up with the finished portrait. This is a big contrast to traditional phased development.

Developing your user stories further

To further develop the user story, see if it can be used in other contexts, in a different order or in other scenarios. Describe these alternative flows in separate stories.

This improves quality incrementally. Working in short cycles allows early tests with real test data, real user and realistic scenarios.

Bundle user stories into groups

User stories need to be grouped to form a clearer structure.

There are many ways to group user stories, for example, based on the work process. An item can maybe pass different stages such as draft, under review or published. You can also group by how the items are handles, e.g. create, modify and delete. Another basis for grouping is by business rules, e.g. system used by an administrator in comparison to system used by an end user with more limited permissions.

You can also group by how much effort is needed to fulfil the story. One example might be adding a first credit card, compared with adding additional credit cards. Another way is to assess how complex the development task is. Finally, you can group user stories by the input method, for example, uploaded file in comparison to paste from clipboard or to write by hand.

Quality assurance of user stories

One way to assure the quality of user stories is by using the acronym INVEST.

Work out the requirements incrementally

When you write user stories, it is wise to refine them over time in iterations. Start off with finished (minor) parts of the system that can be used by users from day one. Start with basic functionality and add more details later.

Evaluate the entire flow and stop adding additional functionality if the business value added isn’t high enough. Work broad instead of narrow and deep, and follow the user flows of the system. Think about, and plan, testing early. Very often major problems that have to do with the context are discovered too late.

Compile and package

Evaluate the importance of each requirement in relation to each other, and always see if the requirement is aligned with the product vision.

Maybe one persona is more important than another? If so, requirements for this persona should be higher prioritized.

Create a release plan based on the story map. Select features from the top line/the top rows for the first release, then continue to build capabilities to support the entire (base) flow.

If the team has managed to divide the stories into small enough units it should be possible to make a release that consists of stories from most of the features.