Шаблон User Story з критеріями прийняття (безкоштовно)

Шаблон історії користувача виконує дві функції. Він змушує кожну історію відповідати на одні й ті самі три запитання (хто, що, чому), і надає команді фіксоване місце, де записати, як вони зрозуміють, що історія завершена. Ця сторінка надає вам обидва: формат однієї рядка, повний шаблон картки, який можна скопіювати, критерії прийняття у трьох форматах, визначення готовності та завершеності, а також приклади з розв’язками.

Якщо ви новачки в історіях користувача, почніть з нашого гайда щодо як писати user stories, а потім поверніться сюди за шаблоном.

Шаблон історії користувача в один рядок

Більшість команд використовують формат, який з’явився в команді Connextra в Лондоні у 2001 році та був популяризований книгою Майка Коуна User Stories Applied (його огляд історій користувача є гарним вступом):

Як [тип користувача], я хочу [дію або можливість], щоб [вигода або результат].

Кожна частина виконує конкретну функцію:

• «Як» називає реальний тип користувача, наприклад, покупця вперше, адміністратора облікового запису або постійного пацієнта. «Як користувач» не дає команді жодної інформації. Якщо у вас є персони, використовуйте їхні імена.
• «Я хочу» описує, що робить або отримує користувач, його словами. Це не повинно описувати рішення («випадний список», «кеш Redis»); залиште простір для команди, щоб вона знайшла найкраще рішення.
• «Щоб» визначає цінність. Саме цю частину найчастіше пропускають, і вона є найважливішою: вона дозволяє команді запропонувати простіший варіант, який забезпечує той самий результат, і дозволяє власнику продукту визначати пріоритети.

Майте на увазі, що речення не є вимогою. Рон Джеффрі описував історію як три речі: картку, розмову та підтвердження (3 Cs). Шаблон допомагає з карткою та підтвердженням (критеріями прийняття); ніщо не замінює розмову.

Повний шаблон картки історії користувача

Одного рядка достатньо для стікера. У інструменті для беклогу зазвичай потрібно кілька додаткових полів, щоб історію можна було ранжувати, оцінювати та тестувати. Ось поля, які ми вважаємо корисними; видаліть ті, які ваша команда ніколи не читає.

Тримайте розділ «Контекст і нотатки» коротким: якщо він перетворюється на сторінку специфікації, історія, ймовірно, є епіком і потребує розбиття (наш посібник зі створення карт історій показує, як це зробити).

Шаблон історії користувача, готовий до копіювання

Вставте це в поле опису задачі в Jira або Linear, шаблон бази даних Notion або перший рядок електронної таблиці. Замініть текст у квадратних дужках і видаліть рядки, які не використовуєте.

• ID: [PROJECT-000]
• Назва: [Дієслово + об’єкт, наприклад «Експортувати рахунки в CSV»]
• Історія: Як [тип користувача], я хочу [дія або можливість], щоб [вигода].
• Контекст: [Чому це важливо зараз; посилання на дослідження, тикети підтримки або метрики]
• Критерії прийняття: [3–7 тестованих умов у форматі чек-листа або Given/When/Then]
• Поза межами: [Що ця історія свідомо не охоплює]
• Дизайн: [Посилання на макет або прототип]
• Залежності: [Інші історії, сервіси або рішення]
• Пріоритет: [Обов’язково / Бажано / Можливо або позиція в беклозі]
• Оцінка: [Очки або розмір, заповнюється командою]
• Відкриті питання: [Усе, що має бути вирішено до початку спринту]

Рядок «Поза межами» економить суперечки: запис «не включає скидання через SMS» на картці кращий, ніж виявлення на огляді спринту, що хтось вважав, ніби це включено.

Що таке критерії прийняття і хто їх пише

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

• Тестованими: хтось може сказати «так» або «ні» без тлумачень. «Швидко» не є тестованим; «результати з’являються протягом двох секунд» — так.
• Специфічними для цієї історії: правила, що стосуються кожної історії (код переглянуто, розгорнуто на staging), належать до визначення «готовності», а не сюди.
• Вільними від деталей реалізації: вказуйте, що відбувається, а не який компонент чи таблиця це забезпечує.
• Чесними щодо помилок: принаймні один критерій має охоплювати некоректний ввід, відсутність мережі або відсутні дозволи.
• Малою кількістю: три-сім критеріїв — це здоровий діапазон. Більше десяти зазвичай означає, що історію слід розбити.

Власник продукту несе відповідальність за критерії, але не повинен писати їх самостійно. Найнадійніша модель — коротка розмова з уточненням між продуктом, розробником і тестувальником (часто називають «троє друзів»): яка цінність, як це буде реалізовано, як це може зламатися.

Формат 1: критерії прийняття у вигляді чек-листа

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

Історія: Як постійний клієнт, я хочу скинути пароль через електронну пошту, щоб я міг повернутися до свого облікового запису без звернення до підтримки.

• На екрані входу є посилання «Забули пароль?», яке відкриває форму скидання.
• Відправлення зареєстрованої електронної адреси надсилає посилання для скидання протягом однієї хвилини.
• Посилання для скидання працює лише один раз і втрачає чинність через 30 хвилин.
• Новий пароль має відповідати наявним правилам пароля, а форма вказує, яке правило не виконано.
• Після успішного скидання всі інші сесії для цього акаунта завершуються.
• Відправка неареєстрованої адреси показує те саме підтвердження, що й зареєстрована, тому форма не розкриває, хто має акаунт.

Використовуйте чек-лист, коли поведінка є простою. Його недолік у тому, що він приховує початковий стан і порядок подій, які наступний формат робить явними.

Формат 2: Given/When/Then (Gherkin) критерії приймання

Given/When/Then походить від розробки, орієнтованої на поведінку, яку Дан Норт описав разом із Крісом Меттсом у Introducing BDD. Кожен сценарій визначає початковий контекст (Given), дію (When) та очікуваний результат (Then). Gherkin — це структурована версія цієї мови, яку використовують Cucumber та подібні інструменти, тому сценарії, написані таким чином, можуть стати автоматизованими тестами з мінімальними змінами формулювань.

Ось та сама історія скидання пароля у вигляді трьох сценаріїв, включаючи два негативні шляхи.

Сценарій 1: скидання за дійсним посиланням

• Given у мене є акаунт, зареєстрований на anna@example.com
• And я запросив скидання пароля
• When я відкриваю посилання для скидання протягом 30 хвилин і ввожу новий пароль, що відповідає вимогам
• Then мій пароль змінюється
• And я виходжу в систему
• And інші сесії завершуються

Сценарій 2: термін дії посилання минув

• Given я запросив скидання пароля більше ніж 30 хвилин тому
• When я відкриваю посилання для скидання
• Then я бачу повідомлення, що посилання втратило чинність
• And мені пропонується кнопка для надсилання нового посилання

Сценарій 3: адреса електронної пошти не зареєстрована

• Given акаунт для sam@example.com не існує
• When я запитую скидання пароля для sam@example.com
• Then я бачу те саме повідомлення про підтвердження, що й зареєстрований користувач
• And жодного електронного листа не надсилається

Коли один сценарій потрібно виконати з кількома вхідними даними (наприклад, списком паролів, які мають бути відхилені), Scenario Outline у Gherkin дозволяє написати його один раз і перелічити вхідні дані у таблиці прикладів.

Зберігайте Gherkin зрозумілим: одна поведінка на сценарій, і пишіть декларативно («When I request a reset link»), а не крок за кроком («When I click the Send button»), щоб сценарій залишався актуальним після редизайну.

Формат 3: критерії приймання на основі правил

Для історій, що переважно складаються з бізнес-правил (ціноутворення, еліжність, валідація, дозволи), формулюйте правила безпосередньо та додавайте сценарії лише для складних комбінацій.

Історія: Як покупець, я хочу застосувати код знижки при оформленні замовлення, щоб сплатити акційну ціну.

• Правило 1: один код на замовлення.
• Правило 2: відсотковий код застосовується лише до підсумкової вартості товарів, а не до доставки чи податків.
• Правило 3: код з мінімальною сумою покупки застосовується лише тоді, коли підсумкова вартість до знижки відповідає мінімуму.
• Правило 4: прострочені або використані коди відхиляються з повідомленням, що пояснює причину.
• Правило 5: видалення товарів, внаслідок чого підсумкова вартість падає нижче мінімуму, призводить до видалення коду та відображення сповіщення.

Ви можете поєднувати формати в одній історії. Частий шаблон — правила для логіки плюс два-три сценарії Given/When/Then для випадків, які люди найімовірніше можуть неправильно зрозуміти.

Визначення готовності та визначення завершеності

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

Список Scrum Guide визначає визначення завершеності як формальний опис стану Інкременту, коли він відповідає вимогам до якості продукту. Визначення готовності не є частиною Scrum; це практика, яку багато команд впроваджують, щоб запобігти потраплянню напіврозумілої роботи в спринт (див. глосарій Agile Alliance щодо визначення готовності і визначення завершеності).

Приклад визначення готовності

• Історія відповідає шаблону, а поле «so that» заповнено.
• Критерії приймання написані та переглянуті командою продукту, розробки та тестування.
• Дизайни прикріплені, або команда погодила, що вони не потрібні.
• Залежності виконано або заплановано.
• Команда оцінила історію, і вона вміщується в один спринт.

Приклад визначення завершеності

• Усі критерії приймання виконано.
• Код переглянуто та злитий у головну гілку.
• Автоматизовані тести покривають нову поведінку, і весь набір тестів проходить успішно.
• Базові перевірки доступності пройдено (використання клавіатури, мітки, контрастність).
• Випущено на середовище staging, і власник продукту його прийняв.

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

Практичні приклади

Ще дві історії з різних типів продуктів. Ще сорок прикладів дивіться у нашому прикладах user story.

SaaS: запрошення колеги (чек-лист)

Як адміністратор робочого простору, я хочу запрошувати колегу за електронною поштою, щоб вони могли бачити наші проєкти без того, щоб я ділився своїми даними для входу.

• Адміністратори бачать кнопку «Запросити» на сторінці учасників; інші ролі її не бачать.
• Адміністратор може обрати роль (Учасник або Адміністратор) перед надсиланням.
• Лист із запрошенням надходить протягом однієї хвилини, а посилання дійсне протягом семи днів.
• Запрошення адреси, яка вже є учасником, відображає повідомлення замість надсилання другого запрошення.

E-commerce: зберегти товар на потім (Given/When/Then)

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

• Якщо я увійшов у систему і маю два товари в кошику
• Коли я обираю «Зберегти на потім» для одного товару
• Тоді цей товар переміщується до мого списку збережених
• І загальна сума в кошику перераховується без нього
• Якщо я не увійшов у систему
• Коли я обираю «Зберегти на потім»
• Тоді мене просять увійти, і товар зберігається після входу

Використання шаблону в Jira, Linear, Notion або електронній таблиці

У Jira використовуйте тип задачі Story і вставте шаблон у опис (або зберігайте критерії приймання в окремому полі, якщо ваш адміністратор додав таке). У Linear збережіть його як шаблон задачі. У Notion розмістіть його в шаблоні бази даних, щоб нові сторінки беклогу відкривалися заповненими. Електронна таблиця з одним рядком на історію підходить для першого беклогу або воркшопу, але переходьте до трекера, коли кілька людей починають редагувати. Незалежно від інструменту, тримайте шаблон достатньо коротким, щоб люди заповнювали його.

Складання історій та критеріїв приймання за допомогою ШІ

Мовні моделі добре справляються з першим чернеткою історій та критеріїв. Робочий промпт:

Ви — продуктовий менеджер. Для наведеної нижче функції напишіть історії користувача у форматі «Як [користувач], я хочу [дія], щоб [вигода]». Для кожної історії додайте 3–6 критеріїв приймання у формі Given/When/Then, включаючи принаймні один негативний сценарій. Окремо перелічте всі припущення та відкриті питання. Функція: [опис функції, користувачів та обмежень].

Потім перегляньте чернетку, як будь-який інший вхідний матеріал:

• Чи є користувач реальним сегментом, з яким ви спілкувалися, чи загальним «користувачем»?
• Чи вигадала модель бізнес-правила, обмеження чи цифри? Замініть їх власними.
• Чи є негативні сценарії тими, з якими стикаються ваші користувачі? Чернетка ніколи не замінює розмову щодо уточнення.

Часті запитання

Хочете, щоб команда перетворила ваші історії на робочий програмний продукт? Принесіть свій беклог або просто ідею, і ми допоможемо вам сформувати її в історії розміру спринту та розробимо. Дивіться наші щомісячні плани розробки.