Working with User stories: Gov.uk Guide

User story is an integral part of flexible development techniques. With it, you can break up your work into a series of tasks, the implementation of each of which adds tangible value to the project implementation process. All these tasks can be discussed and distributed in importance independently of each other.

A user story or “user stories / wishes of the user” is a methodology based on other agile practices, including the principles of continuous delivery and direct communication with users. It is not enough just to understand what your user will be like; the real user of your system should stay close to the team for a long time.


User story briefly describes:

• the person using the system (customer);
• what should be contained in this system (note);
• what the user needs it for (goal).

A user story can be added to the backlog of a project at any stage of the sprint by any member of the team. The project owner decides how to coordinate and prioritize the user's wishes, and selects them at the beginning of each sprint cycle.

Discuss the story before planning stages with:

• relevant team members;
• experts on this issue;
• stakeholders.

User wish cards

The user's wish is a card with a title and several lines of text. Your cards can be both virtual and material. When developing a large product / system, store them in a digital format, and then arrange material cards as part of the sprint planning.
')
When making a card with the user's wish, make sure that it (the wish) is well formulated. Do not skip the part that explains the need to create this element of the system just because it may cause you difficulties.

You can develop a list of acceptance criteria when the user requirements for the system are met. It should be a reminder to test or verify certain things that may be affected by the discussion. But no need to focus on it when determining the amount of work based on the user story.

If the wish is too voluminous, break it into smaller parts, as with such an approach the chance increases that as a result you get a code ready for subsequent use.

Structure

The card is compiled according to the standard scheme:

• title;
• customer (actor, actor);
• note;
• target.

It does not reflect every little thing, but you should discuss the user story in detail at the right time for the team.

Movement "from the goal"

Creating useful software systems is time consuming, so you need to be sure that you solve the right problem. In flexible methodologies, the “from reverse” approach is used - what is the system user trying to get at the output? If you dive into the solution of this issue without a sufficient understanding of your users, you risk solving the wrong problem or finding a solution that does not really suit your users in real life. Therefore, the most important part of a user story is its goal.

purpose

Understanding the objectives will help you in deciding whether you have fulfilled the user's requirements, in other words, whether the work you have done is in line with the goal facing the user?

When writing a user story with your development team, always start by thinking about and discussing your user's goals:

• Why does he want to use this system?
• What is he trying to achieve?
• What made him look for your service?
• In what conditions does he use it: at home / at work / by telephone / while caring for a child?
• how often does he use it?

Suzanne and James Robertson give excellent advice on this subject in the third edition of the book Mastering the Requirements Process.

Customer (actor)

A detailed description of the customer (actor) will help you break the process of building interaction into logically related segments.
Sometimes the customer will be a user of your system, in other cases - an administrator, technician or manager of your organization.
Make sure that you know your users well enough on the basis of the work already done or previous research. If not, take the time to expand your understanding of users.

Notes

Use them as a block to transfer information about the main type of interaction, which should be considered as part of the user experience. Remember that the card should not reflect every detail of this interaction.

Direct communication with the user

Agile teams prefer face-to-face communication with detailed documentation.

Face to face conversation:

• faster;
• more accurate than written documentation;
• allows developers to build a detailed model of user goals, workflows, constraints, and many issues that need to be taken into account when developing software.

The card is just a template, a guarantee that the conversation will take place at the right time. Use the cards and several options to complete the conversation to estimate how much time you will need to complete the work on the user story and put it in the backlog of the project.

When development starts directly, chat with users or their representatives for details of requirements. A user story is a summary of all conversations, sketches and diagrams - not just a card. It is not necessary to record and store all conversations, but you need to correctly interpret them into automated tests or working code.

Using user stories at this stage will allow you to avoid “information overload” - a painful state in which you are trying to guess the details of a goal from the distant future.

User story acceptance criteria

Acceptance criteria help, in particular, to understand whether the user's wish is fulfilled. They accompany the communication between the developer and the user or his representative and are evaluated prior to the start of development. Fix them on the back of the card only if, according to the team, they contain user considerations that can be forgotten in the future. Sometimes writing acceptance criteria on a card is useful if the user or the user's representative is unavailable and there is no one to replace him for a face-to-face meeting.

Stories "work" only for agile teams

The success of a user story depends on regular communication directly between developers and users or its representatives. Your service manager and other user representatives should be available to communicate with developers every day, and have plenty of time to think and answer your questions. Don't underestimate how much time this work can take!

Where the user wishes come from

Wishes can come from many places, but the most common sources include:

1. Workshops on writing a user story (most often occur at the initial stage of the project); A team of developers and interested parties gather to designate the wishes of users.
2. Interviews with real users - ideally, you should find several users to whom the development team will have constant access.
3. User representatives on your team - this could be a service manager or product owner.
4. Observation - see how real users work on your system.

We discussed this material with a number of startups of the 4th Accelerator of IIDF [the next Accelerator Open Day will take place next Thursday, February 12, 2015 ]:

1. Do you use a user story? What sources do you refer to when creating a user story?






Do you agree with the statement that the user story technique is only suitable for agile teams?







In addition to User stories, we also reviewed other Gov.uk materials (with comments by Russian experts):

• User-Designed Product Design
• Basic aspects of Agile methodology