Пользовательская история (User Story) и Job Story — два формата записи потребности в первичной документации: они фиксируют что нужно пользователю или системе и зачем, не подменяя полную спецификацию. В Agile истории чаще всего живут как элементы Product Backlog; в классических проектах — как секция FRD или приложение к SRS. Здесь — синтаксис, критерии качества, декомпозиция и карта историй; как писать — в этой заметке, как классифицировать среди видов спецификации — в 02.03.03 Спецификация требований (SRS, Use Case, User Story). Выбор между User Story, Job Story и Use Case — в 04.03 Use Case vs User Story — выбор подхода, место среди BRD/SRS/FRD — в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).
1. Суть темы
Пользовательская история — краткое описание функциональности с точки зрения актора (пользователя, роли или внешней системы), фиксирующее кто, что и зачем.
User Story — это обещание обсуждения, а не исчерпывающее описание. (Рон Джеффрис)
Job Story — альтернативный формат на базе Jobs-to-be-Done (JTBD): фокус на ситуации, мотивации и ожидаемом результате, а не на персоне.
Обе формы — прикладная narrative-запись функциональных требований поверх классификации из 02.03.01 Классификация требований (БТ, ФТ, НФТ). В 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) нет нормативного шаблона User Story: ISO 29148 оперирует структурированными требованиями, а истории — agile-практика документирования.
2. Ключевые понятия
2.1. Классический формат User Story
Шаблон, популяризированный Конором Ливсом (Connextra) в начале 2000-х:
Как <роль/тип пользователя>,
Я хочу <действие/цель>,
Чтобы <получаемая ценность/результат>.Пример (B2C):
Как зарегистрированный покупатель, я хочу просматривать историю заказов за последний год, чтобы повторно купить понравившиеся товары без повторного поиска.
Пример (системный аналитик, интеграция):
Как потребляющая система (consuming system), я хочу получать webhook об изменении статуса заказа, чтобы синхронизировать складской учёт без опроса API.
- Роль — не должность из оргструктуры, а актор в контексте системы: персона, сегмент или внешняя система. Персоны и заинтересованные стороны — в 02.01.03 Анализ заинтересованных сторон (Stakeholder Map); роли в UI и RBAC — в 02.02.04 Прототипирование и UI-UX-исследования.
- Действие — атомарное, однозначное намерение.
- Ценность — выгода для актора, а не технический эффект («чтобы данные сохранились в БД» — повод пересмотреть формулировку).
2.2. INVEST
Критерии качества истории (Билл Wake); общие принципы качества записи требований — 02.04.03 Управление качеством требований:
| Критерий | Расшифровка | Пояснение |
|---|---|---|
| I — Independent | Независимая | Можно реализовать без жёсткой блокировки другими. После сплиттинга по CRUD или шагам процесса — проверить независимость заново. |
| N — Negotiable | Обсуждаемая | Детали уточняются в диалоге, реализация может меняться. |
| V — Valuable | Ценная | Ощутимая выгода пользователю или бизнесу. |
| E — Estimable | Оцениваемая | Команда может дать относительную оценку; иначе нужна проработка (spike). Процесс оценки — 02.05.04 Совместная оценка трудоёмкости требований. |
| S — Small | Маленькая | Умещается в одну итерацию; крупное — эпик для декомпозиции. |
| T — Testable | Тестируемая | Есть объективные критерии приёмки; формулировку можно проверить на однозначность ещё до кода — 08.03 Тестирование требований (статическое тестирование). |
2.3. Три «С»: Card, Conversation, Confirmation
Рон Джеффрис выделяет три составляющих:
- Card (карточка) — краткая формулировка на стикере или в задаче (Jira, Trello).
- Conversation (обсуждение) — диалог, где рождаются детали: 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии.
- Confirmation (подтверждение) — критерии приёмки (Acceptance Criteria). Детальный разбор форматов AC и BDD — в 02.04.02 Критерии приёмки (Acceptance Criteria); связь с V&V — 02.04.01 Верификация и валидация (V&V).
Иллюстрация Confirmation (один пункт из полного набора AC):
- При отсутствии заказов за 365 дней отображается сообщение «У вас пока нет завершённых заказов».
Нефункциональные ограничения (производительность, безопасность) выносят в отдельные истории или явные пункты AC — см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.
2.4. Job Story
Формат предложен Аланом Клементом (Alan Klement); команда Intercom и Paul Adams популяризировали его в продуктовой среде на базе Jobs-to-be-Done (Клейтон Кристенсен). Мост к бизнес-анализу: «работа, которую нужно выполнить» связывает ситуацию с проблемой и ожидаемым результатом — см. 02.01.01 Определение бизнес-проблем и возможностей, 02.01.02 Цели, KPI и критерии успеха (SMART, GQM); полная теория JTBD здесь не разбирается.
Когда <описание ситуации>,
Я хочу <мотивация/действие>,
Чтобы <ожидаемый результат>.Пример (мобильный UX):
Когда я в метро с плохим сигналом, я хочу читать сохранённые офлайн-статьи, чтобы скоротать время без интернета.
Пример (batch / операции без UI):
Когда ночной cut-off batch упал в 02:00 и часть платежей зависла в статусе «обработка», я хочу получить сводный отчёт с ID транзакций и кодами ошибок, чтобы перезапустить только проблемные записи, не трогая успешные.
Ситуация важнее роли: формат уместен, когда контекст сильнее сегмента пользователя.
2.5. Синтаксис User Story и Job Story
Ниже — различие структуры формулировки и типичных дефектов записи. Критерии выбора формата, Use Case и иных артефактов — в 04.03 Use Case vs User Story — выбор подхода.
| Аспект | User Story | Job Story |
|---|---|---|
| Фокус | Актор (кто) | Ситуация и мотивация (когда и зачем) |
| Структура | Как <роль>, я хочу…, чтобы… | Когда <ситуация>, я хочу…, чтобы… |
| Контекст | Может подразумеваться | Ситуация — обязательный элемент |
| Типичный дефект | Устаревшие персоны, лишние роли | Формальная «когда» без реального контекста |
Жёсткого правила «B2B = US, B2C = JS» нет: в B2B часто нужны Job Stories для edge-cases, в интеграциях без UI — User Story с актором «система».
3. Как применяется в работе аналитика
3.1. Место в документации и бэклоге
| Контекст | Как используют истории |
|---|---|
| Scrum / Kanban | Product Backlog Item — часто User Story + AC; Scrum не требует шаблон User Story для PBI |
| FRD / дополнение к SRS | Секция «функциональные требования» в narrative-форме |
| Эпик → feature → story | Иерархия уровней backlog, именование и правила декомпозиции — 05.02 Scrum и Kanban (аналитик в Agile); трассировка к целям — 02.03.04 Трассировка требований (концепция) |
Карточка выполненной истории остаётся в инструменте, но перестаёт быть предметом планирования — см. 02.05.05 Жизненный цикл требования.
Готовая карточка — 10.01.01 Шаблон User Story: для Job Story используйте то же поле narrative, указав формат «Job Story» (или отдельную секцию «Ситуация / мотивация / результат»). API- и интеграционные детали дополняют шаблонами вроде 10.01.04 Шаблон спецификации REST API.
3.2. Декомпозиция и сплиттинг
Эпики и темы дробят на истории, готовые к реализации. Шесть способов по Майку Кону:
- По шагам процесса (workflow): регистрация → авторизация → заказ.
- По бизнес-правилам: с НДС / без НДС.
- По типу данных: поиск по названию, артикулу, диапазону цен.
- По сложности: MVP отдельно от расширенной версии.
- По интерфейсам / каналам: ручной ввод, затем интеграция со сканером.
- По операциям CRUD — если каждая операция даёт отдельную ценность.
После дробления проверьте I (Independent) из INVEST.
Пример: эпик «Онлайн-запись к врачу» → US1 (расписание), US2 (бронирование), US3 (отмена).
3.3. Карта пользовательских историй (User Story Mapping)
Метод Джеффа Паттона упорядочивает истории по пользовательскому пути и релизам.
Анатомия карты:
- Ось X (backbone) — последовательность шагов пользователя слева направо (Поиск → Карточка → Корзина → Заказ).
- Ось Y — истории под каждым шагом, сверху вниз по убыванию приоритета; горизонтальный срез задаёт релиз.
- Walking Skeleton — первый сквозной срез: минимальная «нить» через все шаги backbone, дающая end-to-end ценность. Это не слой MoSCoW и не синоним Must-have: скелет — про полноту пути, а не про ярлык приоритета.
MoSCoW или WSJF можно накладывать на срезы релизов при приоритизации — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) — но не смешивайте их с термином Walking Skeleton.
Схема карты (упрощённо):
| Поиск | Карточка | Корзина | Заказ | |
|---|---|---|---|---|
| Walking Skeleton (релиз 1) | по названию | фото, цена | добавить | оплата картой |
| Релиз 2 | фильтр по цене | отзывы | изменить количество | выбор адреса |
| Релиз 3 | история поиска | сравнение | промокод | рассрочка |
3.4. Enabler, spike и Definition of Ready
Не каждый элемент бэклога — user-facing история. В enterprise-практике допустимы enabler, architecture story, spike (исследование перед оценкой) — особенно в SAFe и крупном Scrum; см. 05.02 Scrum и Kanban (аналитик в Agile) и 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках. Их всё равно связывают с ценностью или снимают блокер для поставки.
Эталонные формулировки для SA:
- Enabler (контракт): «Как команда интеграции, мы хотим опубликовать OpenAPI-контракт v1 сервиса заказов, чтобы downstream-системы могли начать разработку consumer'ов» — детали в 10.01.04 Шаблон спецификации REST API.
- Spike (исследование): «Исследовать: Kafka vs RabbitMQ для очереди статусов заказа (≤3 дня), чтобы снять блокер оценки истории по webhook».
Definition of Ready (DoR) — когда история готова в спринт: формулировка, AC, зависимости, оценка. DoR — процессная рамка команды, не часть шаблона карточки; подробнее — 05.02 Scrum и Kanban (аналитик в Agile).
3.5. Гибрид User Story + Job Story
На практике форматы сочетают: эпики и блоки с явной ролью — User Story; edge-cases и ситуативный UX — Job Story. Пример гибрида: эпик «Как администратор, я хочу управлять правами…» + Job Story «Когда я трижды ввёл неверный пароль, я хочу восстановить доступ…».
4. Типовые ошибки и ограничения
- Техническая история без ценности — «обновить фреймворк» без связи с выгодой. Либо переформулировать через пользователя, либо оформить как enabler/spike с явной целью — 05.02 Scrum и Kanban (аналитик в Agile).
- Диктат реализации в карточке — цвет кнопки, placement UI; это ограничивает дизайн.
- Эпик под видом истории — не проходит S (Small); нужен сплиттинг. Уровни backlog — 05.02 Scrum и Kanban (аналитик в Agile).
- AC отсутствуют или превращают карточку в полный SRS/BDD-спек — Confirmation должен быть проверяемым, но не дублировать весь объём спецификации; форматы и границы AC — 02.04.02 Критерии приёмки (Acceptance Criteria).
- Job Story без ситуации — «Когда я хочу скачать отчёт…» теряет смысл формата.
- Путаница Walking Skeleton и MoSCoW на карте — планирование «слоя Must-have» вместо сквозного среза ломает end-to-end поставку.
- Только UI-примеры — забыты batch, админ без интерфейса, API consumer; актором может быть система или оператор.
Связи с другими разделами базы
- 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) — место историй среди первичных артефактов раздела 04.
- 04.03 Use Case vs User Story — выбор подхода — когда история, когда Use Case или иное представление.
- 02.03.03 Спецификация требований (SRS, Use Case, User Story) — история как вид спецификации, не замена SRS.
- 02.03.01 Классификация требований (БТ, ФТ, НФТ) — классификация записей бэклога.
- 02.03.04 Трассировка требований (концепция) — цепочка эпик → story → AC → тест → релиз.
- 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) — ранжирование историй и срезов карты.
- 02.04.02 Критерии приёмки (Acceptance Criteria) — детальная проработка Confirmation.
- 02.04.03 Управление качеством требований — качество записи, не только agile-акроним INVEST.
- 02.05.05 Жизненный цикл требования — от активной карточки бэклога до выполненной.
- 08.03 Тестирование требований (статическое тестирование) — проверяемость формулировки до кода.
- 02.01.03 Анализ заинтересованных сторон (Stakeholder Map) — роли и персоны в формулировке «Как…».
- 02.05.04 Совместная оценка трудоёмкости требований — оценка и spike перед Estimable.
- 05.02 Scrum и Kanban (аналитик в Agile) — бэклог, эпик/feature/story, DoR, enabler в спринте.
- 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках — architecture enabler на уровне программы.
- 10.01.01 Шаблон User Story — готовая карточка для проекта (User Story и Job Story).
- 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) — ISO без шаблона User Story; Agile Extension to BABOK для BA в agile-контуре.
Источники и дополнительные материалы
Книги
- Mike Cohn. User Stories Applied: For Agile Software Development — формат, INVEST, сплиттинг.
- Jeff Patton (with Peter Economy). User Story Mapping: Discover the Whole Story, Build the Right Product — карта историй, backbone, walking skeleton, релизные срезы.
- Roman Pihler. Agile Product Management with Scrum — истории и Product Backlog.
- Intercom. Intercom on Jobs-to-be-Done — JTBD в продуктовой практике.
Стандарты и руководства
- Ken Schwaber, Jeff Sutherland. The Scrum Guide — Product Backlog Item без шаблона User Story.
- IIBA. Agile Extension to the BABOK Guide — документирование историй в бизнес-анализе.
Статьи
- Bill Wake. INVEST in Good Stories, and SMART Tasks — акроним INVEST.
- Ron Jeffries. Essential XP: Card, Conversation, Confirmation — три «С».
- Alan Klement. Replacing The User Story With The Job Story — формулировка Job Story.
- Jeff Patton Associates. User Story Mapping — обзор метода карты.
Инструменты
- Jira, Trello — поля User Story и Acceptance Criteria.
- Avion, StoriesOnBoard — специализированные инструменты для User Story Mapping.