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

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

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

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

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

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

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

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

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

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

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

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

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

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

User Story Mapping

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

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.