User Story: полный гайд по написанию без ошибок

User Story (пользовательская история) — это не просто три строчки по шаблону. Многие команды годами пишут «вроде бы одинаковые» истории, но получают принципиально разный результат. Почему одни истории становятся фундаментом для качественного продукта, а другие — стартовым пистолетом для багов и бесконечных уточнений?

Ответ прост: корень большинства проблем не в кривых руках разработчиков, а в том, как была сформулирована пользовательская история. Точнее — как она не была сформулирована.

В этой статье я разберу типичные ошибки, покажу работающие практики (best practices) и приведу реальные примеры. Вы узнаете, как превратить сырую идею в «зрелую» User Story, которая не оставляет места для недопонимания.

Шаблон все знают наизусть: «Как <роль>, я хочу <действие>, чтобы <ценность>». Загвоздка в том, что многие команды воспринимают его как ритуальную формулу: заполнил три поля — история готова. На деле эта конструкция лишь каркас. Настоящая User Story начинается с разговора.

Реальный пример из практики. Была история:

Звучит отлично, правда? Команда реализовала это за два дня. А через неделю получила шквал звонков от клиентов, которые пытались оплатить покупки, а терминал говорил «недостаточно средств». Оказалось, разработчики показали баланс «на счету», а не «доступный для трат». Разница — заблокированные суммы, pending-транзакции, суточные лимиты. Всё это не было проговорено в критериях приёмки. Команда сделала ровно то, что написано, и получила ровно то, что не нужно бизнесу.

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

Ошибка 1. История без контекста.

Команда получает: «Как пользователь, я хочу загрузить документы». Всё. Ни слова о том, зачем это нужно, какие форматы, есть ли ограничения по размеру, требуется ли предпросмотр, куда эти документы потом денутся. Разработчики дорисовывают картину сами, и в 90% случаев — мимо.

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

Ошибка 2. Гигантские истории, которые живут неделями.

«Как администратор, я хочу управлять пользователями» — в такую историю входит и изменение ролей, и просмотр логов, и массовые операции. Она кочует из спринта в спринт, никто не может сказать, что именно «готово», а тестирование превращается в хаос.

Как исправить: Разбей на атомарные куски. «Администратор может изменить роль пользователя», «Администратор может просмотреть логи действий». Каждая история закрывается за пару дней, скорость поставки растёт, ощущение контроля возвращается.

Ошибка 3. Отсутствие критериев приёмки.

История: «Как клиент, я хочу восстановить пароль, чтобы войти в систему». Вроде понятно. Но что делать, если пользователь запросил сброс дважды? Как долго живёт ссылка? Инвалидируется ли предыдущий токен?

Как исправить: Каждая история должна иметь Acceptance Criteria (критерии приёмки), желательно в формате Given/When/Then (дано/когда/тогда).

Ошибка 4. Желание уместить всё в одну историю ради «полной ценности для пользователя».

Звучит благородно, но приводит к тому, что история становится неподъёмной и непроверяемой. Лучше три истории на один экран, чем одна — на три экрана.

Как исправить: Режь по вертикали, но тонко. Каждая история должна давать небольшую, но законченную ценность.

Ошибка 5. Игнорирование нефункциональных требований.

История «Как пользователь, я хочу войти в систему» умалчивает, что вход должен происходить не дольше 1 секунды, а пароли должны храниться в хэшированном виде.

Как исправить: Дополняй истории нефункциональными «рамками»: производительность, безопасность, масштабируемость.

Любая User Story начинается не с шаблона, а с сырой идеи, которую кто-то принёс. Первый вопрос, который нужно задать себе: «Понятна ли ценность?». Если нет — не иди дальше, пока не выяснишь «Зачем? Кто? Почему?». Потому что без ответа на эти три вопроса история рискует оказаться решением несуществующей проблемы.

Дальше — проверка по INVEST. Это акроним, который помогает оценить качество истории:

• Independent (независимая). История не должна зависеть от других. Если зависит — это риск.
• Negotiable (обсуждаемая). История не должна читаться как готовая инструкция. Оставь пространство для решений.
• Valuable (ценная). Ценность должна объясняться одной фразой. Если нет — переписывай.
• Estimable (оцениваемая). Команда должна понимать, сколько усилий потребуется.
• Small (маленькая). История должна помещаться в один спринт (а лучше — в пару дней).
• Testable (тестируемая). Должно быть понятно, как проверить, что история выполнена.

После INVEST — определение Acceptance Criteria (критериев приёмки) в формате Given/When/Then и добавление нефункциональных требований. Только после этого история попадает в бэклог как «готовая». Это не бюрократия, а страховка от иллюзии понятности.

Три амиго (Three Amigos). Перед взятием истории в спринт аналитик, разработчик и тестировщик вместе за 10–15 минут проходят по ней и синхронизируют понимание. Это убирает эффект «я думал, ты другое имел в виду». В одной команде после внедрения этой практики количество дефектов, связанных с недопониманием требований, упало примерно на 40% за три месяца.

Спецификация по примерам (Specification by Example). Чем сложнее логика, тем полезнее прямо в критериях приёмки привести конкретный пример данных на входе и ожидаемый результат. Не просто «система отклоняет перевод при превышении лимита», а «клиент с дневным лимитом 100 000 ₽ пытается отправить 101 000 ₽, система показывает ошибку „Превышен суточный лимит“». Это разом снимает споры.

DoR (Definition of Ready). Простой чек-лист перед спринтом: у истории должны быть заголовок, роль, действие, ценность, Acceptance Criteria, оценка, отсутствие внешних блокировок. Это дисциплинирует и со временем перестаёт быть бюрократией, становясь привычкой.

Вот пример истории, которая прошла все фильтры.

Заголовок: Просмотр доступного баланса с учётом холдов (заблокированных средств).

Формулировка (шаблон):

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

Критерии приёмки (Acceptance Criteria) в формате Given/When/Then:

• AC1 (нулевые холды):
  • Дано: у клиента баланс 50 000 ₽, нет заблокированных средств.
  • Когда: он открывает главный экран.
  • Тогда: отображается сумма «Доступно 50 000,00 ₽».
• AC2 (с учётом холда):
  • Дано: баланс 50 000 ₽, есть холд на 12 000 ₽.
  • Когда: клиент открывает главный экран.
  • Тогда: отображается «Доступно 38 000,00 ₽», а также показывается пояснение «Заблокировано 12 000,00 ₽».
• AC3 (обновление в реальном времени):
  • Дано: холд снят (например, покупка отменена).
  • Когда: клиент обновляет экран.
  • Тогда: доступный баланс увеличивается на сумму снятого холда в течение 2 секунд.

Нефункциональные требования:

• Загрузка данных не должна превышать 1 секунду (p95).
• Не кешировать данные более 30 секунд.

Видите разницу? Здесь не осталось пространства для интерпретаций. Разработчик понимает, что делать, тестировщик — как проверять, владелец продукта — какую ценность мы поставим.

В 2012 году компания BBC понесла серьёзные репутационные и финансовые потери из-за провала проекта Digital Media Initiative (DMI). Бюджет превысил 100 миллионов фунтов, проект закрыли, не получив работающей системы.

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

После краха DMI BBC кардинально пересмотрела подход к управлению требованиями. Этот пример — напоминание, что недодуманная User Story может стать первой костяшкой в домино, которое обрушит весь проект.

• User Story — это обещание о разговоре, а не техническое задание. Шаблон «Как, Я хочу, Чтобы» — лишь каркас.
• Типичные ошибки: отсутствие контекста, гигантские истории, нет критериев приёмки, игнорирование нефункциональных требований.
• INVEST — фильтр качества: независимая, обсуждаемая, ценная, оцениваемая, маленькая, тестируемая.
• Лучшие практики: Три амиго (аналитик, разработчик, тестировщик), спецификация по примерам, DoR (Definition of Ready).
• Зрелая User Story содержит: шаблон, критерии приёмки в формате Given/When/Then, нефункциональные требования.

Начни с малого: возьми одну историю из текущего бэклога. Проверь её по INVEST. Если не проходит — доработай. Добавь критерии приёмки в формате Given/When/Then. Пригласи аналитика, разработчика и тестировщика на 15-минутную встречу «Три амиго». Синхронизируйте понимание. Ты удивишься, сколько вопросов всплывёт. Лучше задать их до начала разработки, чем после релиза. Удачи.