Working with User stories: Gov.uk Guide

Original author: Gov.uk
  • Transfer
User story is an integral part of flexible development techniques. With it, you can break your work into a series of tasks, the implementation of each of which brings tangible value to the project implementation process. All these tasks can be discussed and sorted by importance independently of each other.

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


The user story briefly describes:
  • person using the system (customer);
  • what should be contained in this system (note);
  • what the user needs it for (purpose).

User story can be added to the project backlog 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 the matter;
  • by interested parties.

User Wish Cards


A user’s wish is a card with a title and a few lines of text. Your cards can be either virtual or tangible. When developing a large product / system, store them in digital format, and then draw up material cards as part of sprint planning.

When issuing a card with the user's wish, make sure that it (the wish) is well formulated. Do not skip the part explaining the need to create this element of the system just because it can cause difficulties for you.

You can develop a list of acceptance criteria when fulfilling custom system requirements. It should be a reminder to test or verify certain things that might be affected in the discussion. But you do not need to focus on it when determining the amount of work based on a user story.

If the wish is too voluminous, break it into smaller parts, since with this approach the chance increases that the result is a code ready for subsequent use.

Structure


The card is prepared according to the standard scheme:
  • heading
  • customer (actor, actor);
  • note;
  • target.

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



Movement "from the goal"

Creating useful software systems is time-consuming, so you need to be sure that you are solving the right problem. Agile methodologies use the “reverse” approach - what does the user of the system try to get at the output? If you delve into the solution of this issue without a sufficient understanding of your users, you run the risk of solving the wrong problem or finding a solution that actually does not suit your users in real life. Therefore, the most important part of a user story is its purpose.

goal

Understanding the goals will help you in deciding whether you have fulfilled the user's requirements, in other words, does the work you have done correspond to the goal the user is facing?

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 phone / while caring for a child?
  • how often does he use it?

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

Customer (actor)

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

Notes

Use them as a unit for conveying information about the basic type of interaction that should be considered as part of the user experience. Remember that the card should not reflect every detail of this interaction.

Communication with the user directly

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

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

A card is just a template, a guarantee that the conversation will take place at the right time. Use the flashcards and several options for starting a conversation to assess how much time you need to complete the work on compiling a user story and place it in the backlog of the project.

When development begins, talk to users or their representatives to clarify the details of the requirements. User story is a generalization 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 in automated tests or working code.

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

Acceptance criteria for user story


Acceptance criteria help, in particular, to understand whether the wishes of the user are fulfilled. They accompany the communication between the developer and the user or his representative and are evaluated before the start of development. Fix them on the back of the card only if, in the opinion of the team, they contain user considerations, which they may later forget about. Sometimes writing the acceptance criteria on a card is useful if the user or user’s representative is unavailable and there is no one to replace him for a personal meeting.

Stories only work for agile teams


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

Where do 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 development team and stakeholders come together to indicate user wishes.
  2. Interview with real users - ideally, you should find several users to whom the development team will have constant access.
  3. User representatives as part of your team - this may be a service manager or product owner.
  4. Surveillance - see how real users work on your system.

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

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

Alexander Bogomolov, ex-project manager, Search
They wrote [user story] even before designing a new version of the site and made, as it seems to me, one big mistake. Didn’t chat with enough potential users before creating stories. As a result, we got stories based on our assumptions, which differed from real needs and could lead the project in the wrong direction.

Leonid Toshchev, Technical Director, Datamonkey
No, rather than yes. We first developed the product and only then communicated with users. Yes, we made certain changes to the content based on reviews, but we never set ourselves the goal of completely basing “tasks” on a user story.

Maria Terkina, co-founder and CEO, Globerland
We never used the term user story, but in fact answered the questions “Who is our customer?”, “How does he use our service?” And “Why does he need our service?”. Information was obtained from applications of customers who come to our website, and from personal communication with those customers who ordered and who did not order our services (translation services).

Alexander Gritsay, CEO, Forecast NOW!
We use the methodology for identifying customer needs using feedback, surveys, live communication (we have a difficult B2B product, and the number of customers is measured in dozens), we rank them, highlight priority ones according to the utility criteria for current and future users, release once a month update.

Olga Kniga, co-founder and CEO, Merku.ru
We use them, like any tool, when it is needed. First of all, when designing a landing page and new product features.

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

Alexander Bogomolov, ex-project manager, Search
I do not quite understand the question - what prevents the creation of stories for any team? Yes - in projects with rigid TK, stories are not very necessary at first glance, but they help to turn such a development into a more meaningful one. They help to understand why this or that function is generally implemented.

Leonid Toshchev, Technical Director, Datamonkey
Now the concept of agile is so blurred - it seems to me that there are no companies that are not agile. Accordingly, user story can be used by everyone.

Maria Terkina, co-founder and CEO, Globerland
I think the user story fits into the agile approach, but can be used in other development approaches.

Maria Podolyak, co-founder of Gagarin Labs
The approach to designing product or interface functionality with user stories is not originally Agile development. The so-called use cases (us cases, examples of use) have existed for a long time in the practice of developing technical specifications. The approach is the same, it was slightly modified to meet the needs of Agile.

In private conversations of the two product managers, you can hear: “Oh, we started to make a new product for recognizing the color of cats in photographs!” In response, you can hear: “Give us a case.” We talk with user stories, because this is the only way to understand what “user pain” is being solved, what innovative or radically different way to solve the problem is used, how it happens at the functional level. History helps to "try on" a decision for yourself.

User stories are also used in interface design. I met this approach at the School of Interface Design. We painted a portrait of the user (they are also sometimes called personas), wrote a script for the story, then we cut out the interface from paper in order to play the script or story (this was how the hypothesis was tested).

In November, I tried to apply the same approach to design a company’s or product’s content strategy at a seminar at the School of Internet Marketing in Nizhny Novgorod. And it turned out great. So the approach is applicable to everything in the product: functionality, interface, marketing, etc. It makes one think with the user's head, understand his problem, and not fall into hallucinations.
So Agile did nothing new, just adapted the existing approach to fit his needs.

Olga Kniga, co-founder and CEO, Merku.ru
The user story technique is not suitable for teams, but for specific cases and stories - when you can select a fairly standard user who will represent a typical group. Another useful way to use them is to return to understanding who the project is being done for: for a team or a person who starts a vertical asphalt paver and is distracted from the context of solving a problem of a specific group of people.


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


Also popular now: