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

Конспект статьи. Автор оригинала: Сергей Прощаев (sproshchaev, OTUS)

Техлид из финтеха объясняет, почему формально одинаковые user story дают разный результат: история не была по-настоящему проработана. Шаблон «Как роль, я хочу действие, чтобы ценность» — лишь каркас, настоящая история начинается с разговора.

Типичные ошибки

• Нет контекста: «загрузить документы» без форматов, размеров и дальнейшей судьбы файлов.
• Гигантские истории, кочующие из спринта в спринт. В примере автора разбиение одной истории на шесть ускорило поставку.
• Нет критериев приёмки: у сброса пароля не описаны повторные запросы, срок жизни ссылки, инвалидация токена.
• Попытка вместить всю ценность в одну историю вместо тонких вертикальных срезов.
• Забыты НФТ: время отклика, безопасное хранение паролей.

Путь к зрелой истории

Проверка ценности → формулировка по шаблону → проверка по INVEST → критерии приёмки в Given/When/Then → НФТ. Только после этого история готова для бэклога.

Практики сильных команд

• Three Amigos — аналитик, разработчик и тестировщик за 10–15 минут проходят историю до спринта. В команде автора дефекты из-за недопонимания снизились примерно на 40% за три месяца.
• Specification by Example — в критериях конкретные данные и ожидаемый результат.
• Definition of Ready — чек-лист перед взятием в спринт.

Дано: баланс 50 000 ₽, заблокировано 12 000 ₽
Когда: клиент открывает главный экран
Тогда: показана доступная сумма 38 000 ₽ и пояснение о блокировке

Исторический пример — провал проекта Digital Media Initiative в BBC с бюджетом больше 100 млн фунтов. Среди причин назывались размытые требования и слабая связь с бизнес-целями.