User Story — это короткое описание функциональности глазами пользователя: кто хочет сделать что и зачем. Такой формат помогает всей команде говорить на одном языке и держать фокус на ценности, а не на красивых экранах или внутренней архитектуре. Классическая формула («Как [роль], хочу [действие], чтобы [ценность]») прижилась именно потому, что заставляет ответить на три главных вопроса — кто, что и зачем.
В Scrum истории чаще всего выступают «кирпичиками» бэклога: их обсуждают на рефайнменте, берут в спринт, демонстрируют на обзоре. При этом важно помнить: Scrum не требует именно формата “user story” — в гайде говорится о «элементах бэклога продукта» (PBI), которые должны быть понятны и приводить к готовому инкременту. Истории — удобный, но необязательный способ описания таких элементов.
Что дает история команде
- связывает задачу с понятной пользовательской пользой и бизнес-целью
- упрощает коммуникацию между ролями — обсуждаем поведение и результат, а не реализацию
- удобно «переводится» в план: из истории рождаются конкретные подзадачи разработки, дизайна и тестирования.
Полезный практический совет: формулируйте истории простым языком и привязывайте их к конкретным персонам — так делают многие команды и крупные вендоры инструментов.
Как написать историю, которая «поедет»
Начинаем с смысла и держим фокус на пользователе. Несколько рабочих примеров:
- E-commerce: «Как покупатель, я хочу добавить товар в избранное, чтобы вернуться и купить позже».
- Финтех: «Как клиент, я хочу привязать карту к аккаунту, чтобы оплачивать в один клик».
- B2B/SaaS: «Как менеджер склада, я хочу видеть товары с критическим остатком, чтобы вовремя пополнять запасы».
Каждая формулировка прозрачна: понятна роль, действие и ожидаемая польза. Это и есть основа хорошей истории.
Acceptance Criteria: как поймем, что «готово»
Критерии приемки это набор проверяемых условий, при которых история считается выполненной. Они фиксируют границы, снимают двусмысленности и напрямую ложатся в тестовые сценарии. Удобный формат — Given / When / Then: зафиксировали контекст, действие и наблюдаемый результат. Этот подход пришел из BDD и хорошо себя зарекомендовал.
Как писать критерии, чтобы они помогали, а не мешали:
- формулируйте кратко и однозначно — ориентируйтесь на наблюдаемый результат
- покрывайте «счастливый путь», 1–2 ключевых негативных сценария
- добавляйте важные нефункциональные ограничения (скорость, доступность, безопасность)
INVEST: быстрый чек «готовности к работе»
Простой тест качества истории это метод INVEST. Сильная история обычно:
- Independent — максимально независима от других элементов
- Negotiable — детали обсуждаемы на рефайнменте, история фиксирует смысл и границы
- Valuable — дает ценность пользователю/бизнесу в текущем инкременте
- Estimable — объем понятен, крупные неизвестности обозначены
- Small — достаточно мала, чтобы поместиться в спринт; при необходимости режется.
- Testable — по критериям можно написать проверки и показать демо.
Старайтесь всегда проходится по этим пунктам прежде чем выкатывать US команде.
Нефункциональные требования: не забываем важное
Если для ценности критичны быстродействие, надежность или безопасность, зафиксируйте их прямо в критериях приемки или в связанном разделе ограничений:
- «Отрисовка списка — не дольше 300 мс (P95)»
- «Не более одного уведомления на пользователя за 48 часов»
- «Доступность функции — 99,9% в месяц»
Так история остается компактной, но ее результат можно проверить не только функционально, но и эксплуатационно.
Где история живет в процессе
- Истории попадают в Product Backlog и уточняются на рефайнменте: роль, контекст, критерии, риски, зависимости.
- На планировании спринта команда оценивает объем, раскладывает на подзадачи (dev/design/QA) и берет реалистичный набор.
- На обзоре спринта демонстрируется готовый инкремент: показываем сценарии именно по критериям приемки.
- Definition of Done подтверждает, что элемент действительно вошел в Инкремент и может быть продемонстрирован/выпущен.
Кейс: как выглядит связка «история + критерии» в реальных проектах
User Story «Избранное» (e-commerce): “Как покупатель, я хочу добавлять товар в избранное, чтобы вернуться к нему позже и принять решение о покупке.”
Acceptance Criteria
Размещение и доступность действия:
- На карточке товара и на странице товара присутствует явная кнопка/иконка «В избранное» с читаемым состоянием (добавлено/не добавлено).
- Кнопка «Добавить в корзину» также присутствует на странице товара; при нажатии товар попадает в корзину без перезагрузки страницы (+ должно присутствовать сервисное уведомление об успехе).
Добавление и снятие из избранного:
- Если пользователь авторизован и нажимает «В избранное», товар появляется в его списке избранного, иконка/текст меняют состояние на «В избранном».
- Повторное нажатие удаляет товар из избранного, состояние и список синхронизируются.
- Повторное добавление на один и тот же товар не создает дубликатов (идемпотентность).
Авторизация и гостевой сценарий:
- Если пользователь не авторизован, при нажатии «В избранное» отображается предложение войти или зарегистрироваться.
- После успешной авторизации исходное действие повторяется автоматически, и товар добавляется в избранное.
- Для гостя допускается временное локальное избранное (в браузере), после входа локальный список корректно мерджится с серверным без потерь и дублей.
Синхронизация и мультиустройство:
- Изменение статуса (добавлено/удалено) доступно на всех устройствах пользователя в течение ≤ 5 секунд.
- Если действие было выполнено офлайн (мобильное приложение), синхронизация происходит при восстановлении сети, порядок действий и итоговое состояние сохраняются корректно.
Сценарии с недоступным товаром:
- Если товар снят с продажи или отсутствует в наличии, в списке избранного он не отображается в блоке «доступные», а внизу списка появляется секция «Недоступные» с подсказкой («товар недоступен»).
- Переход с элемента «Недоступные» ведет на страницу категории/релевантные рекомендации (не на 404).
- Если товар переиздан с новым идентификатором, в избранном показывается новый товар (если есть маппинг); если маппинга нет — остается запись в «Недоступных».
Связанные действия из избранного:
- В списке избранного доступна кнопка «В корзину» для каждого доступного товара; добавление происходит без ухода со страницы избранного.
- После добавления в корзину статус товара в избранном не меняется автоматически (товар может продолжать оставаться в избранном, пока пользователь не удалит его сам).
Производительность и UX:
- Визуальное обновление состояния «В избранном» отображается ≤ 300 мс (P95) после действия пользователя.
- Список избранного открывается ≤ 1 000 мс (P95) при размере до 200 позиций.
- Элемент управления доступен с клавиатуры и экранных считывателей; есть текстовая альтернатива и фокус-индикатор.
Аналитика и аудит:
- На добавление отправляется событие favorite_added (1 раз на одно действие пользователя), на удаление — favorite_removed.
- В событии не передаются персональные данные, идентификатор пользователя и товара псевдонимизируются.
- Для отладки сервер ведет журнал изменений со штампом времени и источником действия (страница, товара/листинг/избранное).
Обработка ошибок и устойчивость:
- Если сервис избранного недоступен, пользователь получает нейтральное сообщение об ошибке с возможностью повторить попытку, текущее состояние интерфейса не вводит в заблуждение (не ставим «добавлено», если сервер не подтвердил).
- При сетевых сбоях действия ставятся в очередь и выполняются повторно с ограниченным числом попыток, пользователь информируется ненавязчивым тостом.
Ограничения и безопасность:
- Пользователь не может добавлять в избранное более N позиций (порог согласован с продуктом), при превышении выводится пояснение.
- API для избранного требует аутентификации, запросы защищены от CSRF и повторных атак (replay).
Альтернативные сценарии:
- Добавление в избранное с листинга (категория, поиск, рекомендации) — поведение идентично странице товара, не перезагружает страницу.
- Массовое удаление в списке избранного — доступно выделение нескольких позиций и удаление за одно действие
- Переключение вида избранного (сортировка/фильтр по цене, наличию, скидкам) не влияет на функциональность добавления/удаления.
Сценарии исключения (edge cases):
- Товар поменял SKU/вариант (размер/цвет) между добавлением и просмотром избранного: показывается актуальный вариант, если сопоставление возможно, иначе — пометка «вариант недоступен».
- Цена изменилась: в избранном отображается актуальная цена с индикатором «цена изменилась».
- Пользователь удалил аккаунт: список избранного анонимизируется/удаляется согласно политике хранения данных.
- Одновременные действия с разных устройств (гонка состояний): итоговое состояние соответствует последнему по времени подтвержденному действию, конфликты разрешаются по метке времени сервера.
Метрика успеха (для фиксации в задаче)
- Рост доли возвращений к товарам из избранного и конверсии из этих визитов.
- Доля успешных добавлений без ошибок сервера/сети.
- Время отклика на добавление/удаление (P95) в пределах заявленных NFR.
INVEST — аргументированная проверка
- Independent (независимая). История не требует завершения «купонной» или «рекомендательной» функциональности для своей ценности: избранное само дает возвраты к товарам. Зависимости (каталог, аутентификация) стандартны и уже существуют в продукте, при их временной недоступности предусмотрен офлайн-буфер и отложенная синхронизация.
- Negotiable (обсуждаемая). Мы фиксируем смысл (сохранить товар для возвращения) и границы (что входит/не входит в релиз: например, массовое удаление — опционально). Детали UI (вид иконки, формулировки подсказок, расположение кнопок на листингах) обсуждаемы и могут уточняться на рефайнменте без изменения ценности.
- Valuable (ценная). Пользователь получает прямую пользу — может вернуться к заинтересовавшим товарам, бизнес — рост повторных визитов и конверсии из возвратов. Ценность измеряется отдельно от сопутствующих фич (купоны/рекомендации), поэтому эффект атрибутируем.
- Estimable (оцениваемая). Объем понятен: серверная модель избранного, два эндпоинта (add/remove), список и состояния UI, аналитика, обработка ошибок, небольшая синхронизация офлайн. Неизвестности отмечены как риски (мердж гостевого и серверного избранного), для них предусмотрен time-boxed spike.
- Small (небольшая). История укладывается в один инкремент при ограниченном скоупе: добавление/удаление + список + базовые NFR. Расширения (массовые операции, сложные фильтры, кросс-платформенный мердж) можно вынести в последующие истории.
- Testable (тестируемая). Каждый критерий приемки переводится в проверку: happy-path, негативные сценарии (недоступный товар, ошибки сети), NFR по времени отклика, аналитические события, доступность. Набор e2e легко построить по описанным условиям, а логи/события позволяют валидировать идемпотентность и отсутствие дублей.
Если история слишком большая — как «разрезать»
- по сценариям (создание отдельно от удаления)
- по платформам (веб отдельно от мобайла)
- по состояниям (сначала «счастливый путь», затем ключевой негатив)
- по данным (базовый набор полей отдельно от расширенного)
Частые промахи — и что с ними делать
- История подменяется решением («сделать модалку») → возвращаемся к роли и ценности.
- Критерии размыты («быстро», «удобно») → заменяем на измеримые ограничения.
- Нет негативных сценариев → добавляем хотя бы один «что если».
- История слишком велика → режем и выносим исследование в короткий time-boxed spike.
Эти приемы — нормальная практика для зрелых команд и помогают укладываться в короткие итерации.
Подведем итоги
Хорошая User Story — это ясная формулировка роли, действия и ценности плюс проверяемые критерии, которые превращают смысл в результат. INVEST помогает быстро оценить «готовность к работе», а аккуратные NFR защищают от сюрпризов после релиза. В таком виде истории легко проходят путь «бэклог → спринт → демо», а продукт развивается не набором случайных фич, а последовательными, измеримыми улучшениями — именно это и отличает эффективные Agile-команды.
Полезные ссылки
- Курс «Бизнес-аналитик в IT» на Stepik — структурированный старт, шаблоны и практика с проверкой артефактов автором курса + спец предложение для присоединившихся по ссылке ниже, скидка 25%.
Реклама. Семенов А.Д. ИНН 645503942344
- Telegram-канал «Аналитика в IT» — полезные статьи, шаблоны, чек-листы и разборы из реальных задач. Канал будет полезен аналитикам, продактам и тем, кто только начинает свой путь в IT. [ссылка на канал]