Як писати User Stories, щоб було зрозуміло всім

Як писати User Stories, щоб було зрозуміло всім

3 July 2023

  • Автор: Олександр Кононенко

  • Складність: Легко

  • Час: 5 хв

User Story — одна зі складових процесу розробки практично будь-якого IT-продукту за методологією Agile. Її використовують як основу для опрацювання бізнес-логіки додатка, функціональності та дизайну. Помилки під час складання юзер сторі можуть призвести до того, що підсумковий продукт не відповідатиме запитам користувачів. Детальніше про те, що таке User Stories і як їх правильно складати, розповімо в статті.

Що таке User Stories і навіщо вони насправді потрібні 

За своєю суттю User Story — неформальний спосіб побудувати спілкування між юзерами чи стейкхолдерами від бізнесу та девелоперами. Насправді не є залізобетонно обов’язковим елементом, але майже завжди використовується у ситуаціях, коли потрібно зрозуміти та показати взаємодію юзера з IT-продуктом. 

Зазвичай юзер сторі пишуть за такими двома шаблонами:

  1. As a <user/user role> I want <capability> so that <benefits description>.
    Що я, як користувач, хочу чи маю отримати від системи (мається на увазі функціональність), щоб розв’язати свої проблеми/закрити власні потреби.
  2. In order to <receive benefit> as a <role>, I can <goal/desire>.
    Щоб отримати потрібну цінність, конкретна роль має отримати від продукту певну функціональність.

Принципова різниця між шаблонами у фокусі — в другому він направлений на конкретну цінність, визначення якої є одним з основних завдань бізнес-аналітика в принципі. Звісно написання однієї подібної фрази замало для створення повноцінного завдання для розробників — потрібно описати більше деталей, щоб визначити чіткі вимоги для створення якоїсь частки продукту. Допомагають в цьому певна структура побудови User Story та її оцінювання за деякими критеріями якості.

Структура побудови юзер сторі

Основні критерії якості юзер сторі

Є різні підходи для оцінки якості User Story. На практиці часто використовують формулу INVEST через її простоту та універсальність.

INVEST:

  • Independent — User Story має бути цільною та незалежною від інших компонентів, але з урахуванням можливих взаємодій між різними складовими системи. Наприклад, новачки BA часто роблять помилку, коли відокремлюють UI від Backend. Треба пам’ятати, що окремо один від одного вони не мають сенсу для юзерів.
  • Negotiable — юзер сторі має бути приводом для дискусій та пошуку рішень, як краще виконати завдання та задовольнити потреби користувачів.  
  • Valuable — кожна User Story має нести цінність.
  • Estimable — якісну юзер сторі завжди можна прорахувати у story points, годинах тощо.
  • Small — добре, якщо велику User Story можна розбити на менші (декомпозувати), щоб краще проробити кожну та мати більше гнучкості при плануванні процесу розробки.
  • Testable — при написанні сторі обов’язково треба враховувати можливість її тестування.

User Stories обов’язково мають відповідати усім критеріям зі списку INVEST. Якщо цього немає, треба доповнювати чи змінювати, бо погано складена сторі може стати причиною проблем на майбутніх кроках розробки. 

Приклад поганої user story

Уявіть розробку медичного проєкту. BA після спілкування зі стейкхолдерами пропонує такий приклад user story: As a user I want to see patient data from system HC-1 in system CHC-12 so that I can use the data. 

Давайте разом розбиратися, що не так в дані юзер сторі:

  • немає уточнення, який саме user: лікар, пацієнт, адміністратор тощо;
  • patient data може бути різною за форматом, об’ємом;
  • capabilities без чіткого формулювання, бо дані можна створювати, редагувати, видаляти, тому замало вказати to see patient data;
  • benefits залежать від ролі юзера, його дій, інших факторів.

Тобто у цьому прикладі user story явно не вистачає деталей для створення зрозумілого технічного завдання девелоперам. Потрібно декомпозувати на окремі юзер сторі з урахуванням ролей користувачів та іншого.

Приклад хорошої user story

Приклад хорошої user story

Це юзер сторі показу списку товарів в інтернет-магазині, як завдання описуються в Jira. Написано по чіткій та зрозумілій структурі, є потрібні деталі: хто користувач, що він хоче отримати, як має відображатися список продуктів та навіщо.

Декомпозиція User Stories

Декомпозиція User Story — це розділення великої сторі на менші за розмірами, так щоб кожна мала свою цінність для користувача та відповідала іншим критеріям якості. Це робиться для конкретизації ТЗ для розробників, спрощення планування — маленькі за обсягом завдання значно легше помістити в рамки одного спринту, аніж об’ємне. Як приклад, розглянемо сторінку входу на сайт.

Декомпозиція User Stories

Є одне велике завдання — розробити Login Page. Для оптимізації процесу декомпонуємо на шість окремих User Stories, як людина може залогінитися. Кожна сторі незалежна від інших та має свою цінність, при цьому деякі з них при необхідності дробляться ще — впровадити ту ж саму валідацію для номера 5 чи додати кілька етапів для ситуації з нагадуванням пароля.

Як зробити декомпозицію

System

Epic 1

Epic 2

User Story 1-1 User Story 1-2 User Story 2
Tasks 1-1: 1, 2… Tasks 1-2: 1, 2… Tasks 2: 1. 2…

По факту декомпозиція будь-якого проєкту містить дроблення System на Epics — великі шматки функціональності, які неможливо реалізувати за один спринт. Тому далі проводиться розділення на менші частини — User Stories. Їх своєю чергою розбивають на Tasks — саме їх виконують девелопери та тестувальники. 

Звісно схема може бути складнішою, наприклад, між System та Epic буде ще Novel. Але потрібно пам’ятати, що у будь-якому випадку одна юзер сторі завжди належить тільки одному епіку. Коли ж виконують всі Tasks конкретної User Story, її закривають. Так робиться з усіма блоками аж до done усіх Epics — тоді можна сказати, що System побудована.

У Jira процес декомпозиції виглядає так:

Процес декомпозиції юзер сторі у Jira

У цьому випадку System = Backlog, далі йде дроблення на менші блоки. З цікавого — можливість додавання проміжних модулів:

  • Spike — завдання, яке має зробити команда до виконання User Story. Наприклад, для написання якогось модуля потрібно додатково вивчити нову технологію.
  • Enable / Tech Story — технічне завдання, яке розблоковує можливість взагалі приступити до User Story.

Ці модулі потрібні для спрощення планування та менеджменту процесу розробки в цілому.  

Основні підходи до декомпозиції

Підходи Приклади, що, як і завдяки чому можна зробити
by workflow step User Story Mapping.
by business rules Calculate Discount;

Suggest shipping options.

by happy / unhappy flow Sign-up;

Forgot Password.

by input options / platform PDF;

XLS;

Printout.

by data types or parameters Search by name;

Search by title.

by roles Blogger;

Reader.

by action Create / Edit;

Delete;

Inactivate.

User Story Mapping

Story Map — проста та популярна техніка для створення Backlog за допомогою візуалізації підходу до декомпозиції під назвою by workflow step

User Story Mapping

  1. Визначаєте основних юзерів User та їх цілі User Goal в аплікації: щоб щось придбати, рев’ювати тощо.
  2. Розписуєте основні активності користувачів окремими блоками Activity.
  3. Розбиваєте дії юзерів на кроки Steps, які вони мають зробити для виконання певної активності, наприклад, купити товар: залогінитися, обрати, покласти в кошик, придбати.
  4. Розділяєте кроки на окремі User Tasks за пріоритетом — важливіші, тобто обов’язкова та основна функціональність, розташовані вище.

Пиши сторі як профі

Процес User Story Mapping зручний тим, що Story Map можна зробити самому, разом з клієнтом чи командою. При цьому отриманий результат наочний, а усі дані легко занести у будь-який таск-менеджер по типу Jira.

Замість висновку

Правильно створена User Story значно спрощує планування і розробку продукту. Вона допомагає розуміти контекст завдання, а за допомогою грамотної декомпозиції можна врахувати максимум деталей і значно знизити ризики виникнення помилок. Головне пам’ятати, що хороша юзер сторі має зрозумілу структуру і відповідає основним критеріям якості: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Олександр Кононенко

Копірайтер-маркетолог з технічною освітою, досвідом у продажах та маркетингу. Завжди в пошуках найкращих рішень для досягнення поставленої мети. Вважає, що створення текстів — це симбіоз мистецтва та науки.