User Story: как писать и использовать в agile-разработке

Чтобы написать User Story, определите, кому нужна новая возможность и какую задачу человек собирается решить с её помощью. Затем договоритесь с командой, что войдёт в работу и по каким критериям будете принимать результат, чтобы заказчик и разработчики одинаково понимали, что должна делать готовая функция.

На условном примере B2B-портала для оптовых закупок разберём, как подготовить историю к разработке, а краткое определение и состав пользовательской истории (User Story) можно посмотреть в глоссарии.

Как подготовиться к написанию User Story

Прежде чем формулировать историю, разберитесь, в какой ситуации человеку нужна новая возможность и что мешает решить задачу сейчас. Например, запрос «добавить повторный заказ» ещё не объясняет, кто будет пользоваться функцией и какие действия она должна упростить.

Допустим, закупщик регулярно покупает одинаковые расходные материалы и каждый раз ищет их в каталоге заново, хотя в личном кабинете уже есть история заказов. Чтобы понять, как устроена повторная закупка, команда может изучить обращения в поддержку, поговорить с закупщиками и посмотреть, как они оформляют покупки.

Перед подготовкой истории выясните:

• кто выполняет действие и какие у него права;
• в какой ситуации возникает потребность;
• как пользователь решает задачу сейчас;
• какой результат хочет получить;
• какие бизнес-правила и ограничения нужно учесть.

Описывая историю, отделяйте то, что проверили, от предположений, чтобы команда понимала, что известно о потребности пользователя и какие вопросы ещё нужно исследовать.

Как написать User Story, которую команда сможет реализовать

Пользовательскую историю формулируют по шаблону «Как [роль], я хочу [возможность], чтобы [результат]», связывая действие с его пользой для человека. Затем команда уточняет правила работы и критерии приёмки, чтобы определить состав работ и оценить объём разработки.

Такой порядок соответствует модели 3C: краткую запись в карточке дополняют обсуждением и подтверждением результата — Card, Conversation, Confirmation. Договорённости сохраняют в рабочих материалах, чтобы к ним можно было вернуться во время разработки.

Уточните роль и ожидаемую пользу

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

Если уточнить роль и задачу, история будет звучать так:

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

Теперь команда понимает, зачем нужна функция, и может обсуждать способ её реализации. Например, повтор заказа можно запускать кнопкой в истории покупок, а её расположение и поведение проработать при проектировании интерфейсов.

Обсудите правила и границы

Даже такую историю заказчик и разработчики могут понимать по-разному: один ожидает, что система сразу отправит заказ поставщику, а другие планируют перенести товары в корзину. Чтобы согласовать объём работы, обсудите:

• должен ли пользователь проверить черновик или система сразу отправит заказ;
• какие цены нужно использовать — текущие или из прошлого заказа;
• что делать с товарами, которых больше нет в продаже;
• как поступать, если товара недостаточно для прежнего количества;
• можно ли повторить заказ, когда в корзине уже есть товары;
• кому из сотрудников компании доступна функция.

Для первой версии можно договориться, что закупщик переносит товары в пустую корзину по текущим ценам, а затем оформляет покупку обычным способом. Если хотя бы одной позиции нет в нужном количестве, система объясняет причину и ничего не переносит. Прежде чем согласовать такое ограничение с бизнесом, проверьте, смогут ли закупщики повторять обычные для них заказы.

Подробности, которые относятся к нескольким историям, удобнее хранить в общих материалах проекта. Например, в User Flow можно показать последовательность действий и состояния интерфейса, а в техническом задании зафиксировать требования и ограничения. В карточке достаточно оставить ссылки на эти документы, чтобы при изменении правила не пришлось исправлять несколько его копий.

Как проверить историю по INVEST и разделить слишком большую

Билл Уэйк предложил набор критериев INVEST, с помощью которых команда может проверить, понятна ли пользовательская история и готова ли она к разработке:

• Independent — независимая: историю можно реализовать отдельно, а зависимости, которые всё же остаются, известны команде.
• Negotiable — обсуждаемая: участники могут уточнять детали и совместно выбирать решение.
• Valuable — ценная: понятно, какую пользу получит пользователь или заказчик.
• Estimable — поддающаяся оценке: информации достаточно, чтобы оценить работу, а существенные неизвестные команда сначала исследует.
• Small — небольшая: команда может завершить и проверить историю в выбранном рабочем цикле.
• Testable — проверяемая: участники договорились, по каким признакам определят соответствие результата требованиям.

Если история звучит как «Как закупщик, я хочу управлять всеми закупками компании», оценить её будет трудно: за такой формулировкой могут стоять согласование заявок, бюджетирование, повторные заказы и контроль поставок. Поэтому сначала нужно выделить отдельные потребности, а затем определить объём каждой из них.

Повторный заказ тоже может потребовать нескольких историй, если команда планирует поддержать разные ситуации. Например, функцию можно развивать в таком порядке:

1. Сначала дать закупщику возможность повторить заказ, в котором все позиции доступны, с переносом в пустую корзину.
2. Затем разрешить подготовку повторного заказа из доступных позиций, если часть товаров купить нельзя.
3. После этого добавить перенос в уже заполненную корзину, согласовав правила объединения товаров.

После каждого шага пользователь получает возможность, которую можно показать и проверить, но порядок работы зависит от потребностей и технических ограничений. Если почти все прошлые заказы содержат недоступные товары, первую версию придётся расширить, иначе закупщики редко смогут ею воспользоваться.

Разработку базы данных, интерфейса обмена данными (API) и экрана при этом можно выделить в технические задачи внутри истории. Когда же команда делит саму историю, нужно проверить, сможет ли пользователь решить конкретную задачу после завершения каждой части.

Как сформулировать критерии приёмки

Критерии приёмки User Story описывают, при каких условиях работает функция, какой результат получает пользователь и что происходит в исключительных ситуациях. Обсудите эти условия до реализации, чтобы заказчик, разработчики и тестировщики одинаково понимали, что нужно проверить.

Например, фраза «повторный заказ работает корректно» не объясняет, какие цены должна использовать система. Проверяемое условие можно сформулировать точнее: «При переносе товаров в корзину система рассчитывает стоимость по текущим ценам компании закупщика».

Опишите основной сценарий и исключения

Когда поведение зависит от нескольких условий, удобно использовать формат Given–When–Then, или «Дано — Когда — Тогда». Он связывает исходную ситуацию, действие пользователя и ожидаемый результат.

Для повторного заказа основной сценарий будет таким:

• Дано: закупщик вошёл в кабинет, имеет право оформлять заказы, корзина пуста, а все позиции выбранного прошлого заказа доступны в прежнем количестве.
• Когда: закупщик выбирает повтор заказа.
• Тогда: система переносит товары и количества в корзину по текущим ценам компании, а закупщик видит состав и сумму до отправки заказа.

Если одной из позиций нет в продаже или её недостаточно, поведение нужно описать отдельно:

• Дано: закупщик с нужными правами повторяет заказ своей компании, корзина пуста, а одну из позиций нельзя купить в прежнем количестве.
• Когда: закупщик выбирает повтор заказа.
• Тогда: система сообщает, какая позиция недоступна, и оставляет корзину пустой.

Ещё один сценарий понадобится на случай, когда система не может проверить актуальные данные:

• Дано: закупщик с нужными правами повторяет заказ своей компании, корзина пуста, а сервис не возвращает текущие цены или сведения о доступности товаров.
• Когда: закупщик выбирает повтор заказа.
• Тогда: система сообщает об ошибке и не создаёт частично заполненную корзину.

Для простых правил достаточно обычного списка критериев, поэтому переводить каждое условие в Given–When–Then необязательно. Выбирайте формат, в котором участникам легче заметить неоднозначность и договориться об ожидаемом поведении.

Чем критерии приёмки User Story отличаются от Definition of Done

Критерии приёмки относятся к конкретной возможности, например к использованию текущих цен при повторном заказе, а Definition of Done задаёт общие требования к качеству готового результата продукта. В эти требования команда может включить проверку кода, необходимые тесты и обновление документации.

При завершении работы нужно проверить обе группы условий: функция должна выполнять согласованные сценарии и соответствовать принятому Definition of Done. Технические проверки не заменяют проверку пользовательских сценариев, а выполнение сценариев не отменяет общих требований к качеству.

Как использовать истории при планировании и разработке

В командах, которые работают по Scrum, пользовательские истории помогают обсуждать задачи продукта и планировать спринты — рабочие циклы фиксированной длительности. При этом Scrum не требует оформлять все элементы бэклога именно как User Story, поэтому команда выбирает подходящий способ описания работы. Пользовательские истории можно применять и в других гибких процессах.

Кто пишет и уточняет пользовательские истории

Пользовательские истории могут готовить владелец продукта, аналитик или другие участники команды, обсуждая потребность с представителем бизнеса. Разработчики, дизайнеры и тестировщики помогают уточнить реализацию и способы проверки, а ответственность за управление бэклогом в Scrum остаётся у владельца продукта — Product Owner.

При разработке повторного заказа аналитик может уточнять правила закупки, дизайнер — действия в интерфейсе, разработчики — технические зависимости, а тестировщик — редкие и спорные случаи, которые тоже нужно проверить. Распределение работы зависит от состава команды, поэтому его нужно согласовать внутри проекта.

Как уточнять бэклог и определять приоритеты

Бэклог продукта содержит упорядоченный список работ по его развитию, причём подробность пользовательских историй зависит от того, насколько близко команда подошла к реализации. Для ближайших историй нужно согласовать границы и критерии приёмки, а отдалённые можно уточнять позже, когда появится больше информации.

Очередность работы определяют с учётом задач продукта, потребностей пользователей и зависимостей. Например, если закупщики прежде всего не могут найти актуальные документы, решение этой проблемы может оказаться важнее ускорения повторной покупки. Поэтому приоритет функции стоит обсуждать на основе данных о затруднениях пользователей.

Оценка и выбор в спринт

В Scrum объём работы оценивают специалисты, которые будут её выполнять, а при выборе истории в спринт учитывают его цель и возможности команды. Вместе с оценкой нужно зафиксировать, какие условия команда уже проверила и что ещё предстоит выяснить, поскольку эти сведения влияют на состав и сроки разработки.

Например, для повторного заказа можно использовать существующую корзину, но сначала потребуется выяснить, удастся ли получить актуальные цены из учётной системы. Пока команда не проверила такую зависимость, оценивать всю историю без оговорок преждевременно.

Если команда использует story points — условные единицы для сравнения объёма и сложности работ, — не стоит автоматически переводить их в часы или договорную дату. Чтобы определить плановый срок, нужно также учесть доступность специалистов, зависимости и остальные работы по проекту.

Как проверять историю при реализации

Во время разработки участникам нужен доступ к истории, критериям приёмки, макетам и зафиксированным решениям, чтобы уточнять детали по общим договорённостям. Например, при вопросе об изменении цены команда сможет найти согласованное правило или обсудить его с ответственным за продукт.

После реализации проверьте согласованные сценарии, а после выпуска посмотрите, как закупщики пользуются функцией. 

Можно ли менять User Story во время спринта

Пользовательскую историю можно уточнять во время спринта, обсуждая изменения объёма с Product Owner и сохраняя цель спринта и качество результата. Если уточнение влияет на договорные сроки или бюджет, новые условия нужно дополнительно согласовать и зафиксировать до выполнения дополнительных работ.

Полный пример и чек-лист перед разработкой

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

Пример карточки User Story

Название истории: повтор заказа с доступными товарами.

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

В первой версии закупщик может повторить выполненный заказ, если все позиции доступны в прежних количествах и соответствуют текущим единицам и кратности продажи. Система переносит товары по актуальным ценам, а отправку заказа закупщик подтверждает отдельно через существующее оформление покупки, где система ещё раз проверяет цены и доступность.

Критерии приёмки:

1. Закупщик с правом оформления заказов может повторять только выполненные заказы своей компании, причём система проверяет эти ограничения и при прямом обращении к данным.
2. Если корзина пуста и все позиции доступны, система переносит товары и количества прошлого заказа, после чего закупщик видит текущие цены своей компании и новую сумму.
3. Если позиция недоступна, её недостаточно, изменилась единица продажи или прежнее количество не соответствует текущей кратности, система называет проблемный товар, объясняет причину и не переносит заказ.
4. Если корзина заполнена, система предлагает сначала завершить покупку или очистить корзину, сохраняя её содержимое до решения закупщика.
5. Если система не смогла проверить актуальные данные, она сообщает об ошибке и не оставляет частично перенесённые позиции.
6. Если закупщик повторно нажимает кнопку во время обработки, система не добавляет товары второй раз.
7. После переноса закупщик проверяет состав и отдельно подтверждает покупку, поэтому система не отправляет заказ поставщику сразу.

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

До передачи в разработку команда должна проверить, доступны ли статус прошлого заказа, единицы и кратность продажи, цены и остатки, а также повторно ли проверяет данные существующее оформление покупки. Если нужных возможностей нет, придётся дополнить состав работ и пересмотреть оценку.

Что проверить перед началом работы

Перед передачей истории в разработку убедитесь, что команда согласовала основные условия:

• понятно, кто пользователь и какую задачу он решает;
• потребность подтверждают данные, а предположения обозначены как гипотезы;
• границы реализации и исключения позволяют определить объём работы;
• историю можно завершить и проверить в выбранном рабочем цикле;
• критерии описывают поведение функции, включая ошибки и права доступа;
• зависимости известны, а существенные открытые вопросы разобраны;
• участники знают, с кем обсуждать уточнения и где фиксировать решения;
• выполнение истории можно проверить отдельно от ожидаемого бизнес-эффекта.

Если хотя бы одно существенное условие участники понимают по-разному, уточните его и обновите материалы до начала работы, чтобы оценка и приёмка опирались на общие договорённости.

В итоге

Перед передачей User Story в разработку проверьте, сможет ли команда по её описанию объяснить, что получит пользователь и как проверить результат. Если для этого приходится заново обсуждать основные правила, вернитесь к формулировке и критериям приёмки.

Если планируете сайт, личный кабинет или B2B-сервис, расскажите нам о проекте. Обсудим, какие задачи пользователей нужно решить, что включить в первую версию и по каким критериям проверить результат.

См. также

• Пользовательская история (User Story)
• Пользовательский сценарий (User Flow)
• Техническое задание на сайт: из чего состоит хорошее ТЗ и как его использовать в работе
• B2B-портал: этапы разработки и внедрения