User Story и Use Case — это не формальность Jira. Это инструмент, чтобы команда не разошлась по разным углам.

Если вы когда-нибудь приходили на демо и слышали тихое «а мы вообще-то не это имели в виду», хотя в задаче было написано «как пользователь, я хочу…» — вы знаете, о чём пойдёт речь. User Story и Use Case придумали не для того, чтобы заполнить поле в трекере. Их придумали для того, чтобы три человека из разных дисциплин — аналитик, разработчик и тестировщик — поняли требование одинаково.

В этой статье разберёмся, чем User Story отличается от Use Case (нет, это не одно и то же), как писать их по шаблону, какие критерии приёмки нужны и где обычно всё ломается. Будут примеры из e-commerce и банка, диаграмма и таблица сравнения. И, конечно, фраза «мы потом перепишем» — куда без неё.

Что такое User Story и зачем она нужна

User Story (пользовательская история) — это короткое описание функциональности с точки зрения её получателя. Не разработчика, не аналитика, не product owner-а — именно того, кто этой функциональностью будет пользоваться. История пишется человеческим языком и помещается на стикер. Если ваша «история» занимает страницу — это уже не story, это техническое задание в маске.

User Story — это инструмент диалога между командой и заказчиком, а не подробная спецификация. Главная её задача — зафиксировать намерение и ценность, а детали уточняются в разговоре.

Классический шаблон, который придумал Mike Cohn ещё в 2004 году:

1
Как <роль>,
2
я хочу <действие>,
3
чтобы <ценность / результат>.

Три части — три вопроса. Кто? Что хочет сделать? Зачем это вообще нужно? Вот и всё. Если хоть один из этих вопросов остаётся без ответа — история не готова.

Пример хорошей User Story

Как зарегистрированный покупатель, я хочу видеть историю своих заказов за последний год, чтобы быстро найти товар и заказать его повторно.

Здесь есть всё: роль (зарегистрированный покупатель — не «пользователь вообще»), действие (увидеть историю), ценность (быстрый повторный заказ — а не абстрактное «удобство»). Именно последняя часть — про ценность — спасает от того, что в спринт уйдёт фича, которая никому не нужна.

Пример плохой User Story

Как пользователь, я хочу удобный интерфейс, чтобы мне было удобно.

Здесь нет ничего. Роль размытая, действие неконкретное, ценность тавтологична. Такую историю нельзя ни оценить, ни протестировать. Если вы получаете подобное в бэклог — отправляйте обратно с вопросом «что значит удобно и для кого».

Что такое Use Case и чем он отличается от User Story

Use Case (вариант использования) — это более формальный документ, который описывает сценарий взаимодействия пользователя с системой. Если User Story — это записка на стикере, то Use Case — это раскадровка фильма. С основным потоком, альтернативными ветками, исключениями и предусловиями.

Use Case появился задолго до Agile — его в конце 80-х предложил Ивар Якобсон, и оттуда он перекочевал в UML. Поэтому стиль у него академический, структурированный и иногда тяжеловесный. Но именно эта тяжеловесность даёт детализацию, которой User Story принципиально не даёт.

Use Case — это структурированное описание последовательности действий между актором и системой, приводящих к определённому результату. В отличие от User Story, Use Case фокусируется на сценарии взаимодействия, а не на ценности.

Стоит отметить, что в реальной практике это не «или–или». На верхнем уровне команда формулирует User Story (что хочет пользователь), а на этапе проработки сложной механики аналитик может развернуть её в Use Case с альтернативными потоками — особенно там, где много исключений: оплата, авторизация, интеграции.

User Story vs Use Case: таблица сравнения

Примечательно, что в банках, страховых и медицине Use Case до сих пор живут лучше, чем User Story. Регулятор требует прослеживаемости: какой именно сценарий был согласован, что происходит, если клиент ввёл неверный ПИН три раза подряд, и куда уходит логи. На стикере это не уместишь.

Шаблон User Story с критериями приёмки

User Story без критериев приёмки — это пожелание, а не требование. Критерии приёмки (Acceptance Criteria) — это конкретные проверяемые условия, по которым команда понимает: история готова или нет.

Самый популярный формат — Given–When–Then (он же Gherkin), пришёл из BDD:

1
Given <начальное состояние / предусловие>
2
When <действие>
3
Then <ожидаемый результат>

Пример с критериями приёмки

История:

Как зарегистрированный покупатель, я хочу применять промокод при оформлении заказа, чтобы получить скидку.

Критерии приёмки:

1
Сценарий 1: Применение валидного промокода
2
Given покупатель находится на странице оформления заказа
3
And в корзине есть товары на сумму более 1000 ₽
4
When покупатель вводит промокод "SUMMER10" и нажимает "Применить"
5
Then скидка 10% применяется к итоговой сумме
6
And в строке "Скидка" отображается размер вычета в рублях
7

8
Сценарий 2: Промокод не существует
9
Given покупатель находится на странице оформления заказа
10
When покупатель вводит промокод "FAKECODE"
11
Then отображается сообщение "Промокод не найден"
12
And итоговая сумма не меняется
13

14
Сценарий 3: Промокод просрочен
15
Given покупатель находится на странице оформления заказа
16
When покупатель вводит промокод, срок действия которого истёк
17
Then отображается сообщение "Срок действия промокода истёк"
18
And итоговая сумма не меняется

Заметьте: критерии описывают поведение, а не реализацию. Не «промокод проверяется в таблице promo_codes», а «отображается сообщение». Аналитик не должен подсказывать разработчику, какую таблицу читать — это его работа. Аналитик отвечает за то, чтобы поведение было однозначным.

Шаблон Use Case: структура и пример

Use Case традиционно оформляется по структуре, которую популяризировал Алистер Коберн. Минимальный набор полей:

1
Название: <короткое название Use Case>
2
Актор: <роль, инициирующая сценарий>
3
Предусловия: <что должно быть верно до старта>
4
Постусловия: <что верно после успешного завершения>
5
Триггер: <событие, запускающее сценарий>
6

7
Основной поток:
8
  1. Актор делает X
9
  2. Система отвечает Y
10
  3. ...
11

12
Альтернативные потоки:
13
  3a. Если выполнено условие Z, то:
14
      3a.1. Система делает W
15
      3a.2. Возврат к шагу 4 основного потока
16

17
Исключения:
18
  E1. При ошибке N — система делает M

Пример Use Case: «Оформить кредит»

1
Название: UC-101 Оформить потребительский кредит онлайн
2
Актор: Клиент банка (физическое лицо)
3

4
Предусловия:
5
  - Клиент авторизован в интернет-банке
6
  - Клиенту больше 18 лет
7
  - У клиента нет активных просрочек по другим продуктам банка
8

9
Постусловия:
10
  - Заявка на кредит сохранена в АБС со статусом "На рассмотрении"
11
  - Клиент получил уведомление о приёме заявки
12

13
Триггер: Клиент нажимает "Оформить кредит" в личном кабинете
14

15
Основной поток:
16
  1. Система отображает форму с параметрами кредита (сумма, срок, цель)
17
  2. Клиент заполняет параметры и нажимает "Рассчитать"
18
  3. Система рассчитывает ежемесячный платёж и отображает условия
19
  4. Клиент подтверждает условия
20
  5. Система запрашивает скоринг в БКИ
21
  6. Скоринг возвращает решение "Одобрено"
22
  7. Система формирует договор и отображает его клиенту
23
  8. Клиент подписывает договор по СМС-коду
24
  9. Система регистрирует кредитный договор в АБС
25
  10. Система отправляет уведомление клиенту
26

27
Альтернативные потоки:
28
  6a. Скоринг возвращает решение "Требуется ручная проверка"
29
      6a.1. Система отображает сообщение о передаче заявки на проверку
30
      6a.2. Заявка переводится в статус "На ручной проверке"
31
      6a.3. Сценарий завершается
32

33
Исключения:
34
  E1. Скоринг возвращает "Отказ"
35
      E1.1. Система отображает причину отказа (без раскрытия деталей скоринга)
36
      E1.2. Заявка сохраняется со статусом "Отказано"
37
  E2. БКИ недоступен (таймаут более 30 секунд)
38
      E2.1. Заявка сохраняется со статусом "Ожидает повторной проверки"
39
      E2.2. Система автоматически повторит запрос через 15 минут

Важно: то, что в User Story было бы одной строкой («Как клиент, я хочу оформить кредит, чтобы получить деньги»), в Use Case разворачивается в страницу. И каждая ветка тут не для красоты — каждая ловит реальный сценарий, который иначе всплыл бы на проде.

Диаграмма Use Case в UML

UML-диаграмма Use Case — это визуальное представление того, какие акторы взаимодействуют с системой и какие сценарии им доступны. Эллипсы — это варианты использования, человечки — акторы, линии — связи.

graph LR
  Client(["Клиент банка"])
  Operator(["Оператор колл-центра"])
  Scoring(["БКИ / Скоринг"])
  Notify(["Сервис уведомлений"])

  subgraph System["Система интернет-банка"]
      UC1["UC-101<br/>Оформить кредит"]
      UC2["UC-102<br/>Рассчитать платёж"]
      UC3["UC-103<br/>Подписать договор по СМС"]
      UC4["UC-104<br/>Проверить заявку вручную"]
      UC5["UC-105<br/>Получить решение скоринга"]
      UC6["UC-106<br/>Отправить уведомление"]
  end

  Client --> UC1
  Client --> UC2
  Client --> UC3
  Operator --> UC4
  UC1 -.includes.-> UC2
  UC1 -.includes.-> UC3
  UC1 -.includes.-> UC5
  UC1 -.extends.-> UC4
  UC1 -.includes.-> UC6
  UC5 --> Scoring
  UC6 --> Notify

  style Client fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Operator fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Scoring fill:#7b68ee,stroke:#5a4db2,color:#fff
  style Notify fill:#7b68ee,stroke:#5a4db2,color:#fff
  style UC1 fill:#50c878,stroke:#3a9a5c,color:#fff
  style UC2 fill:#50c878,stroke:#3a9a5c,color:#fff
  style UC3 fill:#50c878,stroke:#3a9a5c,color:#fff
  style UC4 fill:#f0a500,stroke:#c88400,color:#fff
  style UC5 fill:#50c878,stroke:#3a9a5c,color:#fff
  style UC6 fill:#50c878,stroke:#3a9a5c,color:#fff
  style System fill:#e0e0e0,stroke:#999,color:#000

На диаграмме видно: основной сценарий «Оформить кредит» (UC-101) включает в себя расчёт платежа, подписание по СМС, скоринг и уведомление — это <<include>>-связи (без них кредит не оформить). Ручная проверка (UC-104) — это <<extend>>-связь: она включается только при определённом условии. Внешние системы (БКИ, сервис уведомлений) — отдельные акторы. Такая схема за минуту даёт картину системы целиком.

Жизненный цикл User Story в команде

Чтобы лучше понять, как User Story двигается от идеи до релиза, посмотрим на её путь через стадии работы. Это та самая воронка, которая отделяет «давайте сделаем фичу» от «фича в проде».

stateDiagram-v2
  [*] --> Idea: Идея от заказчика

  Idea --> Backlog: Сформулирована по шаблону
  Backlog --> Refinement: Взяли на грумминг
  Refinement --> Ready: Прошла DoR
  Refinement --> Backlog: Нужны уточнения

  Ready --> InProgress: Взяли в спринт
  InProgress --> Review: Разработка завершена
  Review --> Testing: Прошла код-ревью
  Review --> InProgress: Замечания ревьюера

  Testing --> Done: Прошла приёмочные тесты
  Testing --> InProgress: Найдены баги

  Done --> [*]: Релиз

DoR (Definition of Ready) — это чек-лист, по которому команда понимает, что историю можно брать в спринт: есть критерии приёмки, понятна оценка, нет блокеров. DoD (Definition of Done) — обратное: что должно быть верно, чтобы историю закрыть. Без этих двух чек-листов история превращается в «мы потом разберёмся», а спринт — в кашу.

Типичные ошибки и как их избежать

За годы работы я насмотрелся на User Story и Use Case всякого. Вот топ ошибок, которые встречаются чаще всего.

Ошибка 1: User Story без ценности

Как пользователь, я хочу, чтобы кнопка стала синей.

Где роль (какой именно пользователь)? Где ценность (зачем синяя)? Это не история, это задача из дизайнерского задания. Если разработчик через полгода вернётся и спросит «почему синяя» — никто не вспомнит.

Как чинить: всегда отвечайте на вопрос «зачем». Если ответ не находится — возможно, фича вам действительно не нужна.

Ошибка 2: Use Case, который описывает реализацию

1. Клиент вводит логин
2. Система делает SELECT из таблицы users по полю login
3. Система сравнивает password_hash с введённым через bcrypt
4. …

Use Case описывает поведение системы со стороны актора, а не внутренние процессы. SQL-запросы и хеши — это уровень технического дизайна, а не варианта использования.

Как чинить: прячьте реализацию за фразой «система проверяет учётные данные». Технические детали — отдельным документом.

Ошибка 3: Технические истории без пользователя

Как разработчик, я хочу мигрировать на PostgreSQL 16, чтобы было современнее.

Иногда это допустимо (для технического долга), но чаще такие «истории» прячут отсутствие бизнес-обоснования. Если миграция нужна — должна быть конкретная польза: новые индексы, скорость, безопасность, поддержка вендора. Без этого технический бэклог растёт быстрее продуктового, и в итоге команда полгода занимается «улучшением фундамента» без новых фичей.

Ошибка 4: Слишком крупная история (epic в маске story)

Как клиент, я хочу полноценный личный кабинет с историей заказов, профилем, бонусной программой и поддержкой.

Это эпик, а не история. Его нельзя оценить, нельзя завершить за спринт, нельзя показать на демо одним куском. Разбивайте по бизнес-сценариям: одна история — одна ценность.

Правило INVEST для проверки:

• Independent — независимая от других
• Negotiable — детали обсуждаемы
• Valuable — несёт ценность
• Estimable — оценимая
• Small — маленькая (умещается в спринт)
• Testable — тестируемая

Если хоть один пункт проваливается — история не готова.

Ошибка 5: Слияние ФТ и НФТ в одну историю

Как клиент, я хочу видеть каталог товаров, чтобы выбрать нужное. Каталог должен открываться за 200 мс, поддерживать 10 000 одновременных пользователей и шифровать персональные данные.

Функциональное и нефункциональное смешалось. Скорость, нагрузка, безопасность — это нефункциональные требования, и они описываются отдельно. История про каталог — про каталог, а нагрузка — это сквозное требование ко всей системе.

Где брать примеры и шаблоны

Готовых шаблонов в интернете полно, но 80% из них — формальные пустышки. Лучше всего собрать собственную библиотеку:

1. Берёте 2–3 крупных Use Case-а из вашего домена.
2. Прорабатываете их со всеми ветками и исключениями.
3. Используете как референс для новых задач.

Если вы работаете в Git и у вас лежат требования рядом с кодом — это вообще идеально (про подход «docs as code» можно почитать в материале о ресурсах). Так требования живут вместе с кодом, и через год их можно сравнить с тем, что реально реализовано.

Заключение

User Story и Use Case — это не два конкурента, а два инструмента из одного ящика. Story — острый и быстрый, для разговоров и стикеров. Use Case — тяжёлый и подробный, для тех мест, где «потом разберёмся» обходится очень дорого. Хороший аналитик умеет переключаться между ними, не превращая одно в другое.

И главное правило, которое выручает чаще остальных: если вы не можете объяснить роль, действие и ценность за одно предложение — у вас ещё не история. У вас намерение. С намерения в спринт лучше не уходить.

PS. Если ваш Use Case в Confluence не открывали полгода — это не Use Case. Это памятник.