User story — это краткое описание функциональности с точки зрения пользователя. Главный инструмент продакта для постановки задач разработке. Формат простой, но ошибки в нём стоят спринтов.
Стандартный формат
Как [роль пользователя], я хочу [действие / возможность], чтобы [цель / ценность].
Примеры:
- «Как незарегистрированный пользователь, я хочу зайти через Google, чтобы не создавать ещё один пароль.»
- «Как PM, я хочу видеть дашборд с ключевыми метриками, чтобы не собирать отчёт вручную каждый понедельник.»
Критерии приёмки (Acceptance Criteria)
Без них user story неполна. Критерии приёмки — это конкретные условия, при которых story считается выполненной.
Формат «Given / When / Then» (Дано / Когда / Тогда):
- Given (контекст): Дано, что пользователь не авторизован
- When (действие): Когда он нажимает «Войти через Google»
- Then (результат): Тогда он перенаправляется на OAuth Google, и после успешной авторизации попадает в личный кабинет
Можно писать и в виде чек-листа: «Кнопка активна только при заполненных полях», «При ошибке показывается текст ошибки», «Работает на мобильных устройствах».
Definition of Done
Отдельно от критериев приёмки — общие стандарты завершения: покрыто тестами, прошло ревью, задокументировано (если нужно). Это не пишут в каждой story, а договариваются один раз в команде.
Типичные ошибки
Слишком большая story. «Как пользователь, я хочу личный кабинет» — это эпик, не story. Дробите до задачи, которую можно сделать за спринт.
Нет «зачем». «Как пользователь, я хочу кнопку экспорта» без «чтобы» лишает команду контекста — она не сможет принять решения по реализации.
Технические требования вместо пользовательской ценности. «Как пользователь, я хочу, чтобы API возвращал JSON» — это не user story, это техзадание.
Нет критериев приёмки. Тогда «готово» у продакта и разработчика — разные вещи.
Эпики и задачи
User story живёт внутри эпика (большой темы) и разбивается на технические задачи (tasks) при планировании спринта. Структура: Эпик → User story → Tasks.
Итог: хорошая user story описывает кто, что и зачем — с конкретными критериями приёмки. Это не бюрократия, а способ убедиться, что команда делает то, что нужно пользователю.