User Story: шаблон, пример и критерии приёмки

User Story, или пользовательская история, — короткое описание полезного результата с точки зрения пользователя. Базовый шаблон: «Как [роль], я хочу [цель], чтобы [ценность]». Например: «Как руководитель команды, я хочу раз в неделю видеть список просроченных задач по ответственным, чтобы заранее перераспределять нагрузку». Критерии приёмки дополняют историю наблюдаемыми условиями результата.

Что такое User Story

User Story — короткое описание полезного изменения с точки зрения конкретной роли. Формулировка отвечает на три вопроса: кому нужен результат, чего человек хочет достичь и зачем это ему. Интерфейс и технические работы описывают позже, когда команда уточнит условия.

История не заменяет требование, макет, техническое решение или тест. Она сохраняет общий смысл работы и создаёт основу для разговора команды. В глоссарии Agile Alliance история описана как функциональный инкремент, который после реализации вносит вклад в ценность продукта. Поэтому формулировка должна говорить о цели пользователя, а не о выбранной технологии.

В Agile история помогает двигаться небольшими полезными изменениями и раньше получать обратную связь. Если нужен более широкий контекст, можно разобрать принципы Agile отдельно. Сама User Story остаётся рабочим инструментом, а не обязательной частью любого процесса.

Чем история отличается от задачи

История описывает результат и его ценность. Задача описывает работу, которую нужно выполнить для получения результата.

Например, «руководитель видит просроченные задачи по ответственным» — пользовательский результат. «Подготовить запрос к базе», «собрать таблицу» и «настроить права» — задачи реализации. Если сразу записать только задачи, команда может выполнить их формально, но не решить исходную проблему.

Use case подробно описывает последовательность взаимодействия участника с системой: предусловия, основной ход и альтернативы. User Story фиксирует роль, цель и ценность, оставляя детали решения для обсуждения. Общее требование вроде «система должна строить отчёты» шире истории: в нём не видны конкретная роль и польза.

Почему одной карточки недостаточно

Короткая запись работает только вместе с обсуждением и подтверждением результата. Модель трёх C разделяет эти части:

• Card — карточка с напоминанием о потребности;
• Conversation — разговор, в котором команда уточняет смысл и ограничения;
• Confirmation — критерии, по которым результат принимают.

Atlassian описывает эти три элемента как карточку, обсуждение и критерии завершения. Если оставить только фразу «Как руководитель…», разработчик и тестировщик будут вынуждены додумывать период, состав данных, права доступа и пустое состояние.

Как написать User Story

Шаблон User Story: «Как [роль], я хочу [цель], чтобы [ценность]». Он помогает отделить потребность от способа реализации. Формулировка может отличаться, но должна сохранять эти три смысловые части.

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

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

Как выбрать роль пользователя

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

Проверьте роль тремя вопросами:

• у этой группы есть отдельная цель в сценарии;
• её поведение или права отличаются от других ролей;
• команда одинаково понимает, кого имеет в виду.

Если у групп разные цели, права или поведение, опишите их отдельными историями. Например, просмотр сводки руководителем и исправление сроков исполнителем лучше описать раздельно.

Как описать цель без решения

Цель показывает, какой результат нужен человеку. Формулировка «получать недельную сводку просроченных задач» оставляет команде варианты: таблицу внутри сервиса, уведомление или другой способ представления. Формулировка «сделать новый дашборд с красивыми графиками» уже навязывает интерфейс.

Последняя часть объясняет ценность. Руководителю список нужен не ради просмотра, а чтобы заранее перераспределять нагрузку. Для бизнеса это снижает риск незаметных задержек. Пользовательская и бизнес-ценность связаны, но их не нужно превращать в рекламное обещание: история фиксирует ожидаемую пользу, а эффект проверяют после выпуска.

Как проверить историю по INVEST

INVEST — эвристика для поиска слабых мест истории. Это не стандарт допуска и не автоматическая проверка. Команда проходит шесть признаков и формулирует вопросы, которые нужно закрыть до разработки.

Проверку проводят не ради формального набора букв. Independent помогает увидеть скрытые зависимости, Negotiable оставляет пространство для решения, Valuable связывает работу с пользой, Estimable показывает достаточность контекста, Small ограничивает объём, Testable требует наблюдаемого результата. Если один признак не выполняется, историю не обязательно отклонять: команда фиксирует риск и решает, что уточнить или отделить.

Для примера главный риск — зависимость от корректных данных о сроках и ответственных. Её нельзя скрыть словом Independent. Зависимость называют явно и решают, можно ли проверить историю на доступной выборке.

Как проверить независимость истории

Независимость означает, что историю можно обсуждать, приоритизировать и по возможности выпускать отдельно. Полная техническая изоляция встречается редко. Важно видеть зависимость и понимать, блокирует ли она результат.

Недельная сводка зависит от данных задач, ролей и прав. Если эти данные уже существуют, история остаётся самостоятельной. Если сначала нужно переделать всю модель прав, зависимость меняет оценку и порядок работ.

Как оценить размер истории

История должна помещаться в понятный рабочий горизонт и описывать одно поведение. В нашем примере не стоит одновременно добавлять экспорт, графики, настройку расписания и прогноз загрузки. Каждый дополнительный результат увеличивает число правил и исключений.

Сигналы слишком большой истории:

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

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

Как написать критерии приёмки

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

Хороший критерий можно проверить одинаково независимо от того, кто проводит приёмку. Слова «удобно», «быстро» и «красиво» требуют измеримой границы или примера. При этом критерий не должен заранее закреплять архитектуру: если результат можно получить другим способом без потери ценности, технический выбор остаётся за командой.

Для одной истории можно использовать список правил или сценарии Given–When–Then. Формат выбирают по сложности поведения. Список удобен для набора независимых условий, сценарий — для связи контекста, действия и результата.

Когда подходит список правил

Список правил подходит, когда условия можно проверить независимо друг от друга. Для недельной сводки критерии могут выглядеть так:

• в сводку попадают задачи со сроком раньше текущей даты и без статуса «Готово»;
• период сводки — последние семь календарных дней;
• задачи сгруппированы по ответственным;
• для каждой задачи видны название, срок и ответственный;
• руководитель видит только доступные ему проекты;
• если просроченных задач нет, система показывает пустое состояние, а не ошибку.

Такая запись задаёт границы результата, но не предписывает структуру запроса, компонент интерфейса или технологию уведомлений.

Когда использовать Given–When–Then

Given–When–Then полезен, когда результат зависит от исходного состояния и действия:

• Дано: у руководителя есть доступ к проекту, в котором две незавершённые задачи просрочены.
• Когда: руководитель открывает недельную сводку.
• Тогда: система показывает обе задачи, группирует их по ответственным и выводит название и срок каждой задачи.

Один сценарий не обязан описывать все правила. Он делает ключевое поведение однозначным, а остальные условия можно оставить списком.

Какие исключения описать в критериях

Добавляйте исключения, которые меняют решение о приёмке. Для примера нужны как минимум два случая:

• негативный: пользователь без доступа к проекту не видит его задачи;
• граничный: при отсутствии просроченных задач отображается понятное пустое состояние.

Дополнительно стоит согласовать границу периода и поведение при временной ошибке источника данных. Не нужно заранее превращать критерии в полный набор тест-кейсов. Руководство Mountain Goat Software подчёркивает, что критерии относятся к конкретной истории, а подробные тесты могут появиться из разных источников.

Чем критерии приёмки отличаются от Definition of Done

Критерии приёмки относятся к одной истории. Definition of Done задаёт общие требования к качеству завершённой работы команды.

Обе проверки нужны. История может выполнить свои критерии, но не пройти общий стандарт качества, например если код не прошёл ревью. Возможна и обратная ситуация: код проверен и документация обновлена, но сводка показывает не тот период. Тогда общий процесс соблюдён, а пользовательский результат не принят.

Как превратить историю в задачи разработки

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

1. подготовить выборку просроченных задач за согласованный период;
2. сгруппировать данные по ответственным и вывести нужные поля;
3. применить права доступа к проектам;
4. добавить недельное представление или уведомление;
5. проверить правила, основной сценарий и исключения.

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

Перед передачей в работу полезно оформить задачу разработчику с контекстом, ожидаемым результатом и ограничениями. В Scrum подготовленная история может стать элементом бэклога и обсуждаться перед спринтом. Отдельно можно изучить работу Scrum, не смешивая User Story со всем фреймворком.

Как выглядит полный пример User Story

Соберём решения в одну последовательность. Исходная просьба: «Сделать новый дашборд с фильтрами, письмами, экспортом и красивыми графиками». После уточнения роли и пользы она превращается в историю о недельном списке просроченных задач. Затем команда добавляет правила, ключевой сценарий и работы реализации.

Почему исходная формулировка плохая

Она начинается с готового решения и объединяет несколько поведений: просмотр, фильтрацию, рассылку и экспорт. Роль пользователя не названа, а слова «красивые графики» нельзя проверить одинаково. Команда не понимает, какой минимальный результат уже принесёт пользу.

Такая просьба может быть идеей для обсуждения, но не готовой историей. Сначала выясняют, кто сталкивается с проблемой, какое решение он принимает и каких данных для этого не хватает.

Как улучшить историю

После правки из исходной просьбы исчезли готовое решение и лишние функции.

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

Какие задачи получились из истории

Из истории появились выборка данных, группировка, проверка прав, отображение и проверка результата. Экспорт и графики не исчезли навсегда: их возвращают в бэклог как отдельные гипотезы, если пользователям действительно нужны эти действия.

Связка «потребность → история → критерии → задачи» сохраняет трассировку: потребность объясняет историю, история задаёт критерии, а критерии обосновывают задачи. Команда может менять техническое решение, не теряя пользовательский результат.

Как вести User Story в Strive

В Strive историю можно оформить обычной задачей. Роль, цель и ценность записывают в описании, критерии — в чек-листе, а уточнения обсуждают в комментариях. В карточке сохраняются история действий и материалы, а в текст можно добавить ссылку на документ или регламент.

Strive не создаёт отдельный объект User Story, не проверяет INVEST и не генерирует критерии автоматически. Команда сама подтверждает формулировку и условия приёмки. Для общего процесса можно организовать продуктовую разработку в пространстве команды и создать канбан-процесс со статусами от уточнения до проверки.

Как обсудить историю с командой

До начала разработки владелец продукта, разработчик и QA читают одну карточку и отвечают на вопросы:

• понятна ли роль и её цель;
• не зашито ли решение раньше времени;
• какие данные и права нужны;
• можно ли проверить каждый критерий;
• какие исключения меняют приёмку;
• помещается ли история в выбранный рабочий цикл.

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

Как контролировать готовность

Готовность контролируют по критериям, связанным задачам и статусам. Чек-лист показывает, какие условия проверены, канбан-доска — где находится работа, а демонстрация результата подтверждает пользовательский сценарий.