В официальном Руководстве по Scrum (Scrum Guide 2020) нет термина “User Story”. Там используется понятие Product Backlog Item (Элемент Бэклога Продукта). Однако 95% Agile-команд в мире используют именно формат Пользовательских Историй. Почему? Потому что это лучший способ переключить внимание с написания требований на обсуждение сути.
User Story — это короткое, простое описание функции с точки зрения человека, которому она нужна.
Формула успеха: Кто, Что и Зачем
Классический шаблон, предложенный Майком Коном, выглядит так:
Как <роль пользователя>, я хочу <действие/функция>, чтобы <ценность/выгода>.
Разберем, почему важна каждая часть:
- Роль (Кто): Мы не делаем продукт для абстрактного “пользователя”. Мы делаем его для “Администратора”, “Нового клиента” или “Забывчивого покупателя”. Это дает контекст.
- Действие (Что): Что человек пытается сделать в системе.
- Ценность (Зачем): Самая важная часть. Если вы не можете объяснить “чтобы что”, задачу, скорее всего, делать не нужно. Это фильтр от бесполезной работы.
| Плохая история (Техническая задача) | Хорошая User Story (Фокус на ценности) | Почему это лучше |
| “Сделать кнопку синей на странице входа.” | “Как пользователь с плохим зрением, я хочу, чтобы кнопка входа была контрастной, чтобы я мог легко найти её и войти в систему.” | Разработчик понимает проблему. Он может предложить не просто синий цвет, а увеличить шрифт или добавить обводку. |
| “Рефакторинг базы данных поиска.” | “Как покупатель, я хочу получать результаты поиска менее чем за 1 секунду, чтобы не тратить время на ожидание.” | Мы продаем не “рефакторинг” (процесс), а скорость (результат). Это позволяет Владельцу Продукта понять ценность инвестиции. |
| “Создать таблицу users с полями login/pass.” | “Как новый клиент, я хочу зарегистрироваться в приложении, чтобы сохранить свои настройки.” | Фокус на цели клиента, а не на структуре БД. Это дает свободу в выборе технической реализации. |
Откуда берутся истории: Связка с Customer Journey Map
Ошибка многих Владельцев продукта — генерировать задачи, глядя в потолок или опираясь исключительно на фантазии стейкхолдеров. Правильный формат user story всегда рождается из реального пути клиента. Чтобы понять, как писать истории, которые действительно решают проблемы, команды используют Customer Journey Map (CJM).
Когда вы раскладываете путь пользователя на CJM, вы находите точки боли. Например, на этапе «Оформление заказа» клиент раздражается из-за необходимости вводить адрес вручную. Эта конкретная боль с карты пути клиента мгновенно конвертируется в задачу: «Как покупатель, я хочу, чтобы мой адрес определялся по геолокации, чтобы не тратить время на ввод текста на морозе». История перестает быть оторванной от реальности фичей и становится хирургическим инструментом для улучшения конкретного шага в CJM.
Чтобы история была действительно качественной, недостаточно просто написать одно предложение. Профессионалы используют две модели.
1. Модель 3C (Рон Джеффрис)
User Story — это процесс:
- Card (Карточка): Физический или цифровой стикер с заголовком истории. Напоминание о том, что нужно что-то сделать.
- Conversation (Разговор): Обсуждение между Владельцем Продукта и Разработчиками. Именно здесь рождаются детали, уточнения и понимание.
- Confirmation (Подтверждение): Критерии приемки (Acceptance Criteria). Как мы поймем, что история готова? Это те самые тесты, которые должны пройти успешно.
Критерии качества INVEST (Билл Уэйк)
На практике invest критерии — это жесткий фильтр. Если тикет не проходит этот чек-лист, разработчики не имеют права брать его в спринт. Аббревиатура задает базовые invest требования к задаче: она обязана быть независимой (не ждать API от соседней команды), обсуждаемой (продакт приносит проблему, а не диктует архитектуру) и ценной для бизнеса. Команда должна быть способна ее оценить, а сама фича обязана влезать в один спринт и иметь четкие сценарии для тестирования. Выпал хотя бы один пункт — задача летит обратно Владельцу продукта на декомпозицию или доработку.
- I — Independent (Независимая): Историю можно сделать отдельно от других. Если для задачи А нужно сначала сделать задачу Б — это плохая архитектура бэклога.
- N — Negotiable (Обсуждаемая): Это не жесткий приказ. Это тема для переговоров. Разработчики могут предложить более дешевое или быстрое решение той же проблемы.
- V — Valuable (Ценная): Она приносит пользу клиенту или бизнесу. Технические задачи “ради техники” не проходят этот фильтр.
- E — Estimable (Оценимая): Команда должна понимать задачу достаточно хорошо, чтобы дать ей оценку (в Story Points или часах). Если оценить нельзя — нужен Spike (исследование).
- S — Small (Маленькая): История должна помещаться в один Спринт. А лучше — занимать не более 2-3 дней работы. Большие истории нужно декомпозировать (дробить).
- T — Testable (Проверяемая): Должны быть понятные критерии, по которым мы скажем “Сделано”. Если нельзя написать тест-кейс, задача не готова.
Главная мысль
User Story — это инструмент эмпатии. Когда вы пишете задачу в формате “сделать таблицу”, вы относитесь к разработчикам как к кодерам. Когда вы пишете “Как покупатель, я хочу…”, вы превращаете их в инженеров, решающих проблемы бизнеса.
Ключевой вывод: User Story считается готовой к разработке (Ready) не тогда, когда она красиво написана, а когда вся команда одинаково понимает, что нужно сделать, зачем это нужно и как мы это проверим.
Часто задаваемые вопросы (FAQ)
Нет. Scrum не обязывает использовать именно этот шаблон. Вы можете описывать задачи как угодно, если это понятно команде и несет ценность. Но формат User Story стал стандартом де-факто, потому что он лучше всего держит фокус на пользователе.
Ответственность за Бэклог несет Владелец Продукта (Product Owner). Однако писать истории может любой член команды. Лучшие истории рождаются в совместном обсуждении (например, на Refinement).
Есть два пути. Первый: попытаться переформулировать их через ценность (как в таблице выше). Второй: использовать “Технические истории” (Tech Stories) или Spikes. Но их количество в Спринте должно быть разумным, чтобы не потерять фокус на бизнес-ценности.
Нет. User Story это элемент Бэклога Продукта (ценность). А Task это технические шаги, которые пишут сами разработчики в Бэклоге Спринта, чтобы реализовать эту историю (например: “создать API”, “верстка макета”, “написание тестов”).
Эпик — это просто очень большая Пользовательская История, которую невозможно выполнить за один Спринт. Эпики используются для обозначения крупных целей или блоков функционала. Чтобы команда могла взять работу в Спринт, Эпик обязательно нужно декомпозировать (разбить) на несколько мелких User Stories, которые соответствуют критерию Small из модели INVEST.