Урок 03.01: User Stories и Acceptance Criteria
Цель урока
Освоить технику написания User Stories — от классического шаблона до продвинутых практик. Научиться проверять качество историй по критериям INVEST, а также формулировать проверяемые критерии приёмки (Acceptance Criteria) через синтаксис Gherkin (Given / When / Then).
Ключевые понятия
- User Story (Пользовательская история) — короткое описание функции с точки зрения пользователя, написанное на естественном языке, которое фиксирует, что нужно сделать, кому и зачем
- Шаблон Connextra (Standard Template) — классический формат User Story: «Как [роль], я хочу [цель], чтобы [причина]»
- Acceptance Criteria (Критерии приёмки) — набор условий, которые должны быть выполнены, чтобы считать историю завершённой (Definition of Done для конкретной истории)
- Gherkin (синтаксис) — формальный язык описания Acceptance Criteria в формате «Дано / Когда / Тогда» (Given / When / Then), используемый в BDD (Behavior-Driven Development)
- INVEST — акроним для оценки качества User Story: Independent, Negotiable, Valuable, Estimable, Small, Testable
- Epic (Эпик) — крупная User Story, которую невозможно выполнить за один спринт; требуется декомпозиция на более мелкие истории
- User Story Mapping — техника визуального упорядочивания историй по оси времени (процесс) и приоритету
1. Что такое User Story и зачем она нужна?
1.1. Определение
User Story (Пользовательская история) — это обещание для будущего обсуждения (promise for a future conversation), а не спецификация. Это главное отличие от классического функционального требования (ФТ) в SRS.
| Функциональное требование (SRS) | User Story |
|---|---|
| «Система должна отправлять email-уведомление при смене статуса заказа» | «Как клиент, я хочу получать email при смене статуса заказа, чтобы быть в курсе его выполнения» |
| Детально, формально | Кратко, с акцентом на ценность |
| Фиксируется навсегда | Живёт до спринта, затем уточняется |
| Не объясняет «зачем» | Обязательно содержит «почему» (причину/ценность) |
| Создаётся аналитиком | Создаётся командой (PO + аналитик + разработчик) |
Суть User Story не в том, чтобы написать текст, а в том, чтобы запустить обсуждение. Команда читает историю, уточняет детали на grooming, и только потом берёт в спринт с детальными Acceptance Criteria.
1.2. Зачем нужны User Stories?
- Ориентация на пользователя — каждая история начинается с «Как [кто]», что заставляет думать о том, кто будет использовать функцию
- Фокус на ценности — «чтобы [причина]» объясняет, зачем это нужно (не «что сделать», а «какую проблему решить»)
- Гибкость — история оставляет пространство для обсуждения деталей реализации, в отличие от жёсткого ТЗ
- Приоритизация — истории можно оценивать, сортировать, переставлять в бэклоге
2. Шаблон Connextra: «Как... я хочу... чтобы...»
2.1. Канонический формат
КАК [роль пользователя / актёр]
Я ХОЧУ [цель / действие / функция]
ЧТОБЫ [ценность / причина / бизнес-выгода]
Разбор каждого элемента:
| Элемент | Вопрос, на который отвечает | Пример |
|---|---|---|
| Как [роль] | Кто это будет использовать? | «Как зарегистрированный пользователь» |
| Я хочу [цель] | Что система должна позволить сделать? | «...я хочу просматривать историю заказов» |
| Чтобы [ценность] | Зачем ему это? | «...чтобы повторить заказ в один клик» |
2.2. Почему «что» неотделимо от «зачем»?
Самая частая ошибка начинающих — опускать «чтобы». История без «чтобы» — это функциональное требование, а не User Story.
| ❌ Плохо (без «чтобы») | Почему плохо |
|---|---|
| «Как пользователь, я хочу видеть историю заказов» | Непонятно, зачем. Разработчик может сделать «просто таблицу», которая не решает бизнес-задачи |
| ✅ Хорошо | |
| «Как пользователь, я хочу видеть историю заказов, чтобы повторить заказ в один клик» | Становится ясно, что история должна содержать функционал «повторить заказ», а не просто просмотр |
Второй пример — как «чтобы» меняет реализацию:
| Казалось бы, одна и та же история... | с разным «чтобы» |
|---|---|
| «Как менеджер, я хочу экспортировать отчёт в Excel» | |
| Вариант 1: «...чтобы отправить его начальнику по email» | → нужна функция «отправить из системы», а не просто скачать XLSX |
| Вариант 2: «...чтобы распечатать и повесить на стену» | → нужна читаемая PDF-версия, а не Excel |
| Вариант 3: «...чтобы загрузить в 1С как закрывающий документ» | → нужен строгий формат с определёнными колонками |
Вывод: Одна и та же фраза «я хочу экспортировать отчёт» с разным «чтобы» приводит к разной реализации. Поэтому «чтобы» обязательно.
2.3. Развёрнутые примеры (5 разных контекстов)
| № | User Story | Почему хорошая |
|---|---|---|
| 1 | Как посетитель сайта, я хочу зарегистрироваться через Google, чтобы не запоминать ещё один пароль | Чётко указаны роль (посетитель), действие (регистрация через Google), ценность (SSO — не запоминать пароль) |
| 2 | Как менеджер по продажам, я хочу видеть дашборд с количеством заявок в статусе «В работе», чтобы понимать текущую загрузку команды | Ценность — не «видеть дашборд», а «понимать загрузку» |
| 3 | Как администратор, я хочу отключить учётную запись сотрудника при увольнении, чтобы он не мог войти в систему после ухода | Ценность — безопасность, compliance |
| 4 | Как оператор склада, я хочу сканировать штрихкод товара при приёмке, чтобы система автоматически сверяла его с накладной | Ценность — автоматическая сверка (исключение ручной ошибки) |
| 5 | Как бухгалтер, я хочу получить отчёт по закрытым заказам за период с детализацией по НДС, чтобы подготовить налоговую декларацию | Ценность — юридическая (налоговая отчётность) |
2.4. Альтернативные шаблоны
| Шаблон | Формат | Когда использовать |
|---|---|---|
| Connextra (классика) | Как [роль] я хочу [действие] чтобы [ценность] | Стандартный случай |
| Feature Injection | Чтобы [ценность], как [роль], я хочу [функция] | Когда ценность важнее роли (ценность в начале) |
| Job Story | Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат] | Для JTBD (Jobs To Be Done), фокус на контексте |
| User Story + Acceptance Criteria | Как... я хочу... чтобы... + Gherkin блок | Стандарт в BDD-командах |
Пример Job Story:
«Когда я получаю крупный заказ, я хочу быстро проверить наличие товара на складе, чтобы сразу подтвердить клиенту срок отгрузки».
Фокус не на роли (кто?), а на контексте (когда?).
3. INVEST: 6 критериев качественной User Story
Акроним INVEST (с англ. — «вкладывать») предложил Bill Wake как чек-лист для оценки User Story.
3.1. I — Independent (Независимая)
Суть: История должна быть по возможности независима от других историй. Это позволяет гибко приоритизировать их.
| ❌ Проблема | ✅ Решение |
|---|---|
| «Создать заказ» зависит от «Авторизоваться», которая зависит от «Зарегистрироваться» | Объединить авторизацию и регистрацию в одну историю, либо выстроить жёсткую последовательность в спринте |
| Story B нельзя начать, пока не сделан Story A | Приоритизировать A выше B, либо сделать А больше, чтобы в ней было «всё для B» |
На практике: Полная независимость недостижима. Но стремиться нужно. Если истории сильно связаны — рассмотрите объединение или одну «базовую» историю + следующую как «расширение».
3.2. N — Negotiable (Обсуждаемая)
Суть: История — не контракт, а приглашение к обсуждению. Детали должны уточняться командой.
| ❌ Плохо | ✅ Хорошо |
|---|---|
| «Система должна отправлять email с темой "Статус заказа изменён", телом письма в формате HTML, содержащим поля: номер заказа, статус, сумма, дата обновления, ссылка на заказ. Письмо должно отправляться не позднее 30 секунд после события» | «Как клиент, я хочу получать уведомления о смене статуса заказа по email, чтобы не заходить в личный кабинет каждый час» |
| Это спецификация, а не User Story. Нет пространства для обсуждения. | У команды есть вопросы: какой email? какой статус? какой дизайн письма? — они решаются на grooming. |
Правило: Если история уже содержит все детали — это не User Story, это функциональное требование. User Story оставляет пространство для решений команды.
3.3. V — Valuable (Ценная)
Суть: История должна приносить ценность пользователю или бизнесу. Технические задачи («Рефакторинг кода», «Обновить библиотеку») — это Task (задача), а не User Story.
| ❌ Техническая задача (не User Story) | ✅ User Story |
|---|---|
| «Заменить HTTP-запросы на gRPC» | «Как клиент, я хочу, чтобы заказы отправлялись мгновенно, чтобы не ждать после нажатия кнопки "Оформить"» |
| «Создать таблицу orders в БД» | «Как менеджер, я хочу создавать заказы в интерфейсе CRM, чтобы фиксировать продажу» |
Важно: Технические задачи тоже нужны, но они не должны быть в бэклоге как User Stories. Их можно:
- Привязывать к User Story как sub-task
- Выделить в технический долг (Tech Debt)
3.4. E — Estimable (Оцениваемая)
Суть: Команда должна быть в состоянии оценить историю (в Story Points или часах).
Если история неоцениваема, возможные причины:
- Слишком большая (Epic) → декомпозировать
- Слишком неясная (не хватает информации) → уточнить на grooming
- Слишком много неопределённости → добавить Spike (исследовательскую задачу) перед историей
Пример неоцениваемой истории:
«Как пользователь, я хочу интегрировать систему со всеми внешними сервисами»
→ Непонятно, сколько сервисов, какие API, есть ли документация. → Декомпозиция: «Интегрироваться с сервисом А (платёжный шлюз)», «Интегрироваться с сервисом Б (доставка)» — каждая становиться оцениваемой.
3.5. S — Small (Маленькая)
Суть: История должна быть такой, чтобы её можно было выполнить за один спринт (обычно 1–3 дня работы одного разработчика).
Признаки слишком большой истории (Epic):
- Несколько этапов сложного процесса
- Множество ролей
- Требует больше 1 спринта
Декомпозиция Epics:
| Epic (слишком большая) | Декомпозиция на User Stories |
|---|---|
| «Как клиент, я хочу оформить заказ» | 1. Добавить товар в корзину |
| 2. Выбрать способ доставки | |
| 3. Ввести адрес доставки | |
| 4. Оплатить заказ | |
| 5. Получить подтверждение |
Граница: Если история оценивается в > 13 Story Points (по Фибоначчи) — это Epic, нужна декомпозиция.
3.6. T — Testable (Тестируемая)
Суть: История должна иметь чёткие критерии приёмки (Acceptance Criteria), по которым можно однозначно определить: «история выполнена».
| ❌ Нетестируемая история | ✅ Тестируемая история |
|---|---|
| «Как пользователь, я хочу, чтобы интерфейс был удобным» | «Как пользователь, я хочу пройти авторизацию за 3 шага (экран → подтверждение → код), чтобы быстро начать пользоваться приложением» |
| «Удобный» — субъективно. Один скажет «да», другой — «нет» | Можно проверить: количество шагов, время прохождения |
Чек-лист тестируемости:
- Можно написать тест-кейс? (да / нет)
- Есть ли численные критерии? (время, количество, статус)
- Понятно ли, что является успешным завершением истории?
- Понятно ли, что является ошибкой / исключением?
4. Acceptance Criteria (Критерии приёмки): синтаксис Gherkin
4.1. Что такое Acceptance Criteria?
Acceptance Criteria (AC) — это набор проверяемых условий, при которых User Story считается выполненной. AC — это Definition of Done для конкретной истории.
Без AC: «Как клиент, я хочу зарегистрироваться» — непонятно, когда история сделана. С AC: «Пользователь ввёл email и пароль → получил письмо → перешёл по ссылке → активирован. Если пароль слишком короткий → ошибка. Если email уже занят → ошибка».
4.2. Два подхода к написанию AC
| Подход | Суть | Пример |
|---|---|---|
| Списком (Checklist) | Простой перечень условий | □ Кнопка «Зарегистрироваться» работает□ Письмо приходит на email |
| Gherkin (Given / When / Then) | Формальный сценарный подход | Дано пользователь на странице регистрацииКогда он вводит emailТогда система проверяет формат |
Мы будем разбирать Gherkin, так как он:
- Исключает двусмысленность
- Автоматически превращается в тест-кейсы
- Позволяет описать нормальные, альтернативные и исключительные сценарии
4.3. Синтаксис Gherkin
Базовый формат:
Функционал: [Название User Story]
Сценарий: [Название сценария]
ДАНО [предусловие / контекст]
И [ещё одно предусловие]
КОГДА [действие пользователя или системы]
И [ещё одно действие]
ТОГДА [ожидаемый результат / постусловие]
И [ещё один результат]
Разбор каждой секции:
| Ключевое слово | Смысл | Вопрос, на который отвечает |
|---|---|---|
| Дано (Given) | Контекст, предусловие. Система находится в определённом состоянии | «Что уже настроено / готово перед началом?» |
| Когда (When) | Действие, которое совершает пользователь (или система) | «Что делает пользователь или что происходит?» |
| Тогда (Then) | Ожидаемый результат: что должно произойти в системе | «Что мы видим / проверяем в результате?» |
| И (And) | Дополнительное условие или действие (для Given, When, Then) | «А ещё что?» |
| Но (But) | Отрицательное дополнение | «А что НЕ должно произойти?» |
4.4. Полный примеры Gherkin
Пример 1: Регистрация пользователя
Функционал: Регистрация нового пользователя
Как новый пользователь
Я хочу зарегистрироваться в системе
Чтобы получить доступ к личному кабинету
Сценарий: Успешная регистрация
Дано я нахожусь на странице регистрации
Когда я ввожу email "ivan@example.com" в поле "Email"
И я ввожу пароль "Qwerty123!" в поле "Пароль"
И я нажимаю кнопку "Зарегистрироваться"
Тогда система отправляет письмо с подтверждением на "ivan@example.com"
И на экране отображается сообщение "Проверьте вашу почту"
Сценарий: Неверный формат email
Дано я нахожусь на странице регистрации
Когда я ввожу email "неправильный-email" в поле "Email"
И я нажимаю кнопку "Зарегистрироваться"
Тогда поле "Email" подсвечивается красным
И отображается сообщение "Неверный формат email"
Сценарий: Email уже зарегистрирован
Дано в системе уже зарегистрирован пользователь с email "ivan@example.com"
Когда я ввожу email "ivan@example.com" в поле "Email"
И я нажимаю кнопку "Зарегистрироваться"
Тогда отображается сообщение "Этот email уже зарегистрирован. Войдите в систему"
Что здесь важно:
- Три сценария: позитивный (happy path) + 2 негативных (ошибка формата, дубликат)
- Конкретные данные: «ivan@example.com», «Qwerty123!» — не абстрактные
- Чёткие ожидаемые результаты (проверка почты, подсветка поля, сообщение об ошибке)
Пример 2: Создание заказа
Функционал: Оформление заказа
Как зарегистрированный клиент
Я хочу оформить заказ с доставкой
Чтобы получить товар на дом
Сценарий: Успешное оформление с оплатой картой
Дано я авторизован в системе
И в корзине есть 2 товара на сумму 2500 руб
Когда я перехожу к оформлению заказа
И выбираю способ доставки "Курьером"
И ввожу адрес: "Москва, ул. Ленина, д.1, кв.10"
И выбираю оплату "Картой онлайн"
И нажимаю "Оплатить"
Тогда я перенаправляюсь на страницу платёжного шлюза
И после успешной оплаты отображается страница с номером заказа "Z-12345"
И на email приходит подтверждение заказа
Сценарий: Ошибка — корзина пуста
Дано я авторизован в системе
И корзина пуста
Когда я пытаюсь перейти к оформлению заказа
Тогда отображается сообщение "Ваша корзина пуста. Добавьте товары"
И кнопка "Оформить заказ" неактивна
4.5. Правила хорошего Gherkin
| Правило | ❌ Плохо | ✅ Хорошо |
|---|---|---|
| Один сценарий — один поток | Сценарий «Регистрация и первый заказ» | Разделить: «Регистрация» и «Оформление первого заказа» |
| Конкретные данные | «Как пользователь, я ввожу неверный пароль» | «Как пользователь, я ввожу пароль "123" (менее 8 символов)» |
| Не смешивать UI и бизнес-логику | «Когда я нажимаю кнопку #login-submit» | «Когда я нажимаю кнопку "Войти"» |
| Не привязываться к конкретной реализации | «Когда AJAX-запрос возвращает 200 OK» | «Когда система проверит email и пароль» |
| Каждый сценарий независим | Сценарий 2 зависит от действий в сценарии 1 | Каждый сценарий задаёт свой Given |
4.6. Три типа сценариев для каждой User Story
Для полноты нужно описать минимум три сценария:
| Тип сценария | Что описывает | Доля |
|---|---|---|
| Happy Path (основной поток) | Всё идёт хорошо, пользователь получает желаемое | 1 сценарий |
| Alternative Path (альтернативный поток) | Другой способ достичь цели (например, вход по SMS вместо пароля) | 1–2 сценария |
| Error Path (исключения) | Что-то пошло не так (ошибка, неверные данные, отказ системы) | 2–3 сценария |
4.7. Gherkin vs Checklist: когда что использовать
| Ситуация | Лучше Gherkin | Лучше Checklist |
|---|---|---|
| Сложная бизнес-логика с ветвлениями | ✅ | ❌ |
| Простые UI-требования (цвет кнопки, расположение) | ❌ | ✅ |
| Автоматизация тестирования (BDD) | ✅ | ❌ |
| Срочно нужен быстрый AC (на grooming) | ❌ | ✅ |
Комбинированный подход:
User Story: Как клиент, я хочу восстановить пароль, чтобы войти в систему
Acceptance Criteria:
# Сценарии Gherkin (формальные)
Сценарий: Успешное восстановление
Дано я нахожусь на странице входа
Когда я нажимаю ссылку "Забыли пароль?"
...
# Дополнительные критерии списком
- Письмо отправляется не позднее 30 секунд
- Ссылка для сброса действует 24 часа
- После сброса старый пароль становится недействительным
5. Как писать User Stories: пошаговый процесс
Шаг 1: Определите пользователя и его потребность
Для начала: не пишите Story, пока не ответите на вопросы:
- Кто пользователь? (одна конкретная роль, не «все»)
- Какая у него проблема? (бизнес-контекст)
- Какую ценность он получит? (зачем это бизнесу)
Шаг 2: Напишите черновик по шаблону Connextra
Не стремитесь к perfect с первого раза. Просто зафиксируйте:
«Как [роль], я хочу [что], чтобы [зачем]»
Проверка: прочитайте «чтобы» — закрывает ли это бизнес-потребность? Если нет — переформулируйте.
Шаг 3: Проверьте по INVEST
| Критерий | Вопрос к себе |
|---|---|
| I | Можно ли эту историю реализовать отдельно от других? |
| N | Оставляет ли она пространство для обсуждения? |
| V | Какая ценность от этой истории? Кому именно? |
| E | Может ли команда её оценить? |
| S | Помещается ли в один спринт? Не Epic ли это? |
| T | Напишу ли я к ней тест-кейс? |
Шаг 4: Добавьте Acceptance Criteria
Для каждой User Story напишите минимум 3 Gherkin-сценария или 5 условий списком:
- Happy Path
- 1–2 Error Path
- 1 Alternative Path (если применимо)
Шаг 5: Вынесите на Grooming
Story идёт в бэклог как черновик. На Backlog Refinement команда:
- Задаёт уточняющие вопросы
- Оценивает Story (Planning Poker)
- Утверждает Acceptance Criteria
- Перемещает в статус «Ready»
6. Типичные ошибки и анти-паттерны
Ошибка 1: User Story как задача для разработчика
| ❌ Неправильно |
|---|
| «Как разработчик, я хочу добавить поле phone в таблицу users, чтобы хранить телефоны» |
Почему это плохо: Написано с точки зрения разработчика, а не пользователя. Ценность не описана.
Как исправить:
«Как менеджер, я хочу видеть номер телефона клиента в карточке заказа, чтобы позвонить ему при проблемах с доставкой»
Ошибка 2: Слишком много «Чтобы» (список)
| ❌ Неправильно |
|---|
| «Как пользователь, я хочу войти в систему, чтобы посмотреть заказы, изменить профиль, написать в поддержку, оплатить...» |
Одна цель — одна User Story. Если несколько целей — декомпозируйте.
Ошибка 3: User Story без Acceptance Criteria
Story без AC — это обещание без пунктов сдачи. Команда не поймёт, когда story сделана. QA не сможет проверить. PO не сможет принять.
Ошибка 4: Смешение эпиков и историй в спринте
В спринте не должно быть Epics. Если Epic попал в спринт — он не будет завершён к концу спринта, что нарушает Definition of Done.
Ошибка 5: User Story = спецификация (чрезмерная детализация)
| ❌ Плохо | ✅ Хорошо |
|---|---|
| «Система должна отображать таблицу с колонками: №, Дата, Клиент, Сумма, Статус. Размер шрифта 14px, цвет #333. Кнопка «Экспорт» в правом верхнем углу...» | «Как менеджер, я хочу видеть список заказов с ключевыми полями, чтобы быстро оценить ситуацию» + AC в Gherkin |
Детали реализации обсуждаются на grooming, а не фиксируются в тексте истории.
Ошибка 6: Нет негативных сценариев
Когда пишут только Happy Path, забывают про:
- Что если пользователь не авторизован?
- Что если данные не найдены?
- Что если внешний сервис недоступен?
- Что если пользователь ввёл некорректные данные?
Правило: Для каждой User Story минимум один Error Path сценарий.
7. User Story Mapping (краткий обзор)
User Story Mapping — это техника визуальной организации историй, предложенная Jeff Patton. Суть:
- По горизонтали — шаги процесса (слева направо: «Зарегистрироваться» → «Найти товар» → «Добавить в корзину» → ...)
- По вертикали — приоритет (сверху — MVP, внизу — будущие версии)
Как этот подход помогает:
- Видно «дыры» в процессе (пропущенные шаги)
- Виден объём MVP (верхний слой)
- Легко приоритизировать (что ниже — можно сдвинуть)
Вопросы для самопроверки
- Из каких трёх обязательных частей состоит User Story по шаблону Connextra? Какую роль играет каждая?
- Что произойдёт, если в User Story опустить «чтобы»? Приведите пример, как одна и та же фраза «я хочу» с разным «чтобы» даст разную реализацию.
- Назовите 6 критериев INVEST. Для каждого приведите пример «плохой» и «хорошей» истории.
- Какая разница между User Story и функциональным требованием?
- Напишите Gherkin-сценарий для User Story: «Как пассажир, я хочу купить билет на поезд, чтобы поехать в другой город». Опишите Happy Path + 1 Error Path.
- Что означает критерий N (Negotiable)? Почему чрезмерная детализация User Story — это плохо?
- Какие три типа сценариев (по Gherkin) должны быть у каждой User Story?
Практическое задание
Кейс: Вы — аналитик в проекте «Приложение для учёта рабочего времени сотрудников» (Time Tracker). Сотрудники должны отмечать начало и конец рабочего дня, а руководитель — видеть сводку по команде.
Задание 1. Напишите User Stories
Составьте 5 User Stories для следующих функций:
- Сотрудник отмечает начало рабочего дня (чекинится)
- Сотрудник отмечает конец рабочего дня (чекаутится)
- Сотрудник просматривает свою статистику за месяц
- Руководитель видит дашборд с загрузкой команды
- Система отправляет напоминание, если сотрудник забыл отметиться до 10:00
Для каждой User Story:
- Используйте шаблон Connextra (Как... я хочу... чтобы...)
- Укажите, какая бизнес-ценность в «чтобы»
- Проверьте по INVEST (напишите 1–2 предложения, почему история соответствует критериям)
Задание 2. Напишите Acceptance Criteria в Gherkin
Возьмите User Story №1 (сотрудник отмечает начало дня) и напишите для неё 4 Gherkin-сценария:
- Happy Path: сотрудник отмечает начало дня в рабочее время
- Error Path: сотрудник пытается отметиться, но уже есть отметка за сегодня
- Error Path: сотрудник пытается отметиться раньше 06:00 (слишком рано)
- Alternative Path: сотрудник отмечает начало дня через Telegram-бота (а не через веб-интерфейс)
Используйте корректный синтаксис Gherkin с ключевыми словами Дано / Когда / Тогда / И.
Задание 3. Декомпозиция Epic
Дан Epic: «Как сотрудник, я хочу управлять своим отпуском, чтобы согласовать даты отдыха с руководителем».
Разбейте его на 3–4 User Stories так, чтобы каждая проходила критерий S (Small) — помещалась в один спринт.
Формат сдачи: Один файл (md) с тремя разделами.
Дополнительные материалы
- Статья (оригинал): Bill Wake — «INVEST in Good Stories, and SMART Tasks» (первая публикация про INVEST)
- Книга: Mike Cohn — «User Stories Applied: For Agile Software Development» (классика)
- Книга: Jeff Patton — «User Story Mapping: Discover the Whole Story, Build the Right Product»
- Книга: Gojko Adzic — «Specification by Example» (Gherkin, BDD)
- Ресурс: Cucumber.io — официальная документация по Gherkin синтаксису
- Шаблон: User Story template с INVEST checks (Confluence / Notion — найти по запросу)
- Видео: «Writing Good User Stories» — Mountain Goat Software (Mike Cohn)