Коротко о главном
Пользовательские истории, или user story, — короткое описание обновления или новой фичи глазами пользователя в бэклоге продукта. Юзер-стори отражают ценность и нужны, чтобы не тратить зря время на разработку новой функции, которая может оказаться никому не нужной. Каждая пользовательская история сначала обсуждается командой проекта, дорабатывается и потом уходит в спринт — то есть в разработку.
Что такое user story
(от англ. user story) — краткое описание функционала с точки зрения конечного потребителя в бэклоге продукта. Именно с неё начинается разработка ПО
Пользовательские истории появились благодаря программисту и одному из главных экспертов в Agile-подходах Майку Кону — он пересмотрел системный подход в работе с ними и обозначил критерии, по которым её можно оценить.
🌟 Хорошая user story:
• Фокусируется на ценности продукта для потребителя
• Короткая, реализовать можно в один спринт
• Содержит чёткие критерии приёмки
• Оценима по сложности работы
Представим, что появился запрос выкатить обновление приложения для иностранных языков, чтобы учащиеся могли исправить свои ошибки. Вот так новую функцию видит пользователь:
«Как человек, который учит иностранный язык, я хочу делать работу над ошибками прямо в приложении, чтобы отрабатывать изученный материал»
User story отвечает на три вопроса:
- Кто — пользователь, который хочет выучить иностранный язык с помощью приложения, вместо того чтобы заниматься с репетитором
- Что хочет сделать — делать работу над ошибками в приложении и отслеживать свой прогресс, не переключаясь на другие сервисы
- Зачем это нужно — чтобы отрабатывать изученный материал и повысить свой уровень знаний
Зачем нужны user story
5 секунд — ровно столько требуется времени, чтобы пользователь ушёл с сайта или приложения, если он не находит нужную кнопку или понял, что после очередного обновления стало ещё хуже.
Юзер-стори создана, чтобы избежать подобных провалов, упростить работу разработчиков, сохранить лояльность пользователей и привести бизнесу новых после обновления функционала.
Подробнее раскроем все вышеперечисленные пункты ниже — не переключайся.
Структура и шаблон user story
Структура юзер-стори проста, как и содержание карточки в бэклоге продукта. Разложим пример юзер-стори с доработкой приложения по иностранному языку. Вот так выглядит карточка с задачей в бэклоге.
В описании видим пользовательскую историю — описание функции глазами потребителя. Ниже — критерии приёмки — чек-лист из требований для тестировщика, которые показывают, что конкретная юзер-стори реализована корректно.
Комментарии — место для обсуждения, где команда проекта задаёт вопросы, прикрепляет ссылки на нужные материалы или, как в примере выше, на созвон.
На этом можно было бы и закончить, но мы не ищем лёгких путей. Создать хорошую пользовательскую историю не так просто, как может показаться на первый взгляд. Если хочешь избежать подводных камней, читай дальше — начинается самое интересное.
Где user story находится в Agile-процессе
Первое и основное, что нужно знать о пользовательских историях, — через них ценность продукта доходит до потребителя. Это один из главных принципов гибких методологий. То, что не ценно, нам не нужно, поэтому мы и выходим из приложения через пару секунд, если не понимаем, куда жмать.
В бэклоге продукта
Юзер-стори обычно отображают карточкой в бэклоге продукта на Канбан-доске. В названии карточки — функционал, который нужно доработать, или фича. В описании — пользовательская история и критерии приёмки.
Бэклог продукта должен быть понятным и постоянно уточняемым. Юзер-стори можно приоритизировать, дополнять, менять и корректировать. После того как все участники рабочего процесса поймут, что пользовательская история достаточно проработана, она уходит в бэклог спринта.
Чем отличается от задачи
Юзер-стори может показаться обычной задачей, но на самом деле общего между ними мало. В карточке с пользовательской историей в бэклоге ты не увидишь списка технических требований.
У user story другая функция — объяснить команде разработки, для кого работаем над продуктом, какую ценность он представляет для пользователя и бизнеса, и дать критерии, по которым можно считать, что продукт готов к релизу.
Как связана с эпиком
Эпик — это контейнер для пользовательских историй, которые объединяет одна цель. Представим другой пример: нужно доработать сайт так, чтобы пользователь мог заказать доставку. Это эпик — большая и абстрактная задача, которую сложно реализовать за один спринт. Потому что, перед тем как заказать доставку, пользователю нужно:
- выбрать понравившийся продукт или быстро найти его по поиску
- добавить его в избранное или в корзину — при этом так, чтобы товары не исчезли из неё, после того как юзер выйдет из приложения или закроет сайт
- в два клика оплатить покупки без лишних телодвижений
Поэтому эпик — большую задачу — нужно поделить на маленькие, но понятные и конкретные пользовательские истории, чтобы доставать их из бэклога в нужное время и работать итеративно.
Как декомпозировать большие user story
Если юзер-стори не помещается в один спринт или её сложно оценить, то это значит, что она слишком большая. В таких случаях её нужно делить на части — то есть декомпозировать по пользовательским сценариям, этапам процесса или бизнес-ценности.
Представим, что у нас есть эпик «Как пользователь, я хочу сделать заказ на сайте». Вот так его можно декомпозировать, чтобы ускорить процесс разработки и постепенно выкатывать уже готовый продукт пользователям.
| Как декомпозировать | Пример |
|---|---|
| По пользовательскому сценарию — фокусируемся на разных типах пользователей и их поведении | • Как новый пользователь, я хочу ввести адрес доставки, чтобы заказать товар впервые • Как возвращающийся пользователь, я хочу выбрать сохранённый адрес, чтобы не вводить его заново • Как пользователь, я хочу выбрать способ доставки (курьер / самовывоз), чтобы получить товар удобным способомКак пользователь, я хочу видеть стоимость и сроки доставки, чтобы принять решение • Как пользователь, я хочу подтвердить заказ, чтобы оформить доставкуКак пользователь, я хочу оплатить заказ онлайн |
| По этапам процесса — фокусируемся на пути пользователя к цели — оформлению заказа. Важно прописывать этот процесс детально, шаг за шагом | Этап 1. Ввод данных • Как пользователь, я хочу ввести адрес доставки, чтобы в системе у продавца было указано, куда доставлять • Как пользователь, я хочу видеть подсказки адреса, чтобы быстрее заполнить форму Этап 2. Выбор доставки • Как пользователь, я хочу выбрать способ доставки, чтобы получить товар удобным способом • Как пользователь, я хочу, чтобы у меня была возможность изменить пункт выдачи, если я выбрал самовывоз и ошибся адресом • Как пользователь, я хочу видеть стоимость доставки, чтобы понимать, за что плачу Этап 3. Проверка заказа • Как пользователь, я хочу увидеть итог заказа (товары + доставка), чтобы проверить перед оплатой Этап 4. Оплата • Как пользователь, я хочу оплатить заказ, чтобы завершить покупку • Как пользователь, я хочу выбрать между оплатой сразу или по получении, чтобы не тратить время на возврат, если товар не понравится Этап 5. Подтверждение • Как пользователь, я хочу получить подтверждение заказа, чтобы быть уверенным, что он оформлен |
| По бизнес-ценности — фокус на прибыли, удержании клиента, повышении конверсии и так далее. Подключаем приоритеты — начинаем с того, что быстрее принесёт реальный результат, а затем улучшаем готовый продукт, чтобы влиять на конверсии и поведение пользователей | MVP — минимальная ценность. То, что может уже принести результат сразу. Держим в голове, что на сайте на данный момент ВООБЩЕ нет функции заказать доставку • Как пользователь, я хочу ввести адрес вручную • Как пользователь, я хочу выбрать один способ доставки (например, курьером) • Как пользователь, я хочу оформить заказ без онлайн-оплаты (оплата при получении) Можно уже принимать заказы — то есть получать деньги. Улучшение для роста конверсии • Как пользователь, я хочу видеть стоимость доставки заранее • Как пользователь, я хочу выбрать из нескольких вариантов доставки Улучшение, чтобы ускорить процесс оформления доставки • Как пользователь, я хочу использовать сохранённые адреса • Как пользователь, я хочу оформлять заказ без повторного ввода данных Улучшение, чтобы дать дополнительную ценность пользователю и мотивировать его вернуться и сделать заказ снова • Как пользователь, я хочу оплатить онлайн • Как пользователь, я хочу получать уведомления о заказе |
Зачем нужны user story в Agile
В целом, как и для всего остального, и правильный ответ ты уже знаешь 🙂 Чтобы создать полезный продукт. Что в это входит — перечислили ниже.
Фокус на ценности для пользователя
Один из главных принципов методологии Agile: любое ПО должно максимально быстро доставлять ценность до конечного потребителя, иначе вся работа будет проделана зря. User story удерживает фокус команды на том, какой результат должен получиться, и показывает, как можно его оценить.
Общий язык для product owner, команды и стейкхолдеров
Описать функцию с точки зрения пользователя — значит, что все, кто участвует в создании продукта, будут понимать, для чего всё это и зачем. Не нужно каждому в отдельности объяснять — это экономит часы бесполезных созвонов.
Более гибкая работа с изменяющимися требованиями
Agile — значит гибкость. Пользовательские истории позволяют её поддерживать. В карточке с историей мы не фиксируем все детали заранее, потому что в процессе разработки можно обнаружить, что пользователю уже не нужен конкретный продукт.
Есть и другие варианты: заказчик резко передумал, бюджеты порезались или появились новые вводные. В любой момент можно дополнить карточку или удалить её.
Проще управлять бэклогом
Если грамотно декомпозировать эпики, то можно отследить приоритетность пользовательских историй. В бэклоге карточки с юзер-стори можно менять местами исходя из того, что нужно сделать в первую очередь. Это влияет на планирование спринта.
Основа для планирования спринта
Если оформить юзер-стори правильно, то проще планировать спринт. Команда будет точно знать, что сможет осилить пользовательскую историю за две или четыре недели. Чёткие и понятные юзер-стори — это залог того, что процесс разработки пройдёт с минимальным количеством ошибок. Но помним, что это может зависеть от множества факторов.
Как писать user story
Подготовили для тебя коротенькое руководство к действию. Для того чтобы написать хорошую пользовательскую историю, нужно всего лишь…
Шаг 1: определить пользователя
На этом этапе стоит понять, чьи проблемы мы хотим решить с помощью новой фичи. Не путай с целевой аудиторией: нам неважно, какой пол у пользователя и где он живёт, нам важнее контекст поведения — то есть действия, которые он совершает, взаимодействуя с продуктом.
Для этого нужно подключить отдел аналитики, посмотреть, какие вопросы поступают в службу поддержки чаще всего, собрать формы обратной связи. Задача на этом этапе — собрать максимум информации из всех источников, которые доступны.
Шаг 2: сформулировать потребность
Если у тебя на руках уже есть вся аналитика и ты знаешь, с какими проблемами сталкиваются пользователи или что они просят улучшить в формах для обратной связи, то ты без труда сможешь определить потребности. Это — костяк юзер-стори, то, что пользователь хочет увидеть в результате работы разрабов.
Типичная ошибка на данном этапе — скатываться в описание технических требований. Если пользователю нужно быстро оплатить заказ, то так и запиши. Настроить кнопку моментальной оплаты и интегрироваться с банками — это уже задачи, с помощью которых разработчики будут реализовывать эту хотелку.
Шаг 3: показать ценность
Возьмём кусочек из предыдущего шага: «Как пользователь, я хочу быстро оплатить заказ» → добавляем к нему союз «чтобы» → записываем ответ.
Вот это «чтобы» — направляющая, которая поможет сформулировать ценность для пользователя. Возвращаемся к аналитике, подбираем варианты и получаем что-то типа такого:
Как новый пользователь, я хочу быстро оплатить заказ, чтобы не искать банковскую карту для ввода данных и не перепроверять их по три раза.
Шаг 4: добавить критерии приёмки
Без критериев приёмки юзер-стори — это что-то абстрактное, что нельзя оценить и протестировать. Как понять, что разработчики реализовали кнопку быстрой оплаты заказа? Очень просто — ввести чек-лист.
Это очень условный пример, но надеемся, что логика мыслей понятна. Можно упростить до метода Given (дано) — When (когда) — Then (тогда). Тогда получится вот так:
- Дано: пользователь нажимает кнопку «Оплатить»
- Когда: всплывает окно с выбором банковской карты для оплаты, пользователь выбирает нужную карту
- Тогда: оплата проходит, заказ оформлен
Критерии приёмки отвечают на один простой вопрос: как понять, что юзер-стори реализована правильно?
Шаг 5: проверить user story перед передачей в работу
После всех перечисленных этапов нужно прогнать написанную пользовательскую историю через критерии качества. Если юзер-стори соответствует им, то тогда можно передать её в работу разработчикам и считать, что они должны успеть всё реализовать за один спринт.
INVEST: критерии качества user story
Готовую пользовательскую историю проверяют по шести критериям качества по технике INVEST. Это чек-лист из шести пунктов, который спасает разработчиков от лишних вопросов и снижает количество переделок.
Расшифровка аббревиатуры INVEST
Independent (независимость)
Пользовательскую историю можно реализовать отдельно, чтобы работать быстрее.
Если она зависит от других задач и к ней нельзя приступить прямо здесь и сейчас, то весь процесс может застопориться.
Negotiable (обсуждаемость)
Майк Кон сказал, что юзер-стори — не контракт. Это значит, что её нужно обсуждать до тех пор, пока у команды не будет общего понимания, как с ней работать.
Valuable (ценность)
Пользовательская история должна быть такой, чтобы сразу было понятно, в чём ценность для пользователя или бизнеса.
Estimable (оцениваемость)
Команда должна понимать, насколько сложно работать над пользовательской историей, чтобы оценить объём работы.
Small (небольшой размер)
Юзер-стори должна быть небольшой, чтобы её можно было успеть реализовать за один спринт.
Testable (проверяемость)
Любую пользовательскую историю можно протестировать с помощью понятных критериев приёмки — то есть условий, при которых мы считаем, что продукт готов к релизу.
Как оценивать и приоритизировать user story
User story чаще всего оценивают в story points — абстрактных единицах, которые показывают сложность задачи и возможные риски. В гибких методологиях задача в бэклоге и есть user story, поэтому её удобно измерять в тех же единицах.
В чём измерять — вопрос индивидуальный и зависит от задач команды. Можно в деньгах, часах, единицах и попугаях. Главное, чтобы всем было понятно и удобно.
За приоритеты отвечает владелец продукта. Он оценивает срочность, риски и зависимости задач, анализирует результаты и распределяет работу по команде.
Недостатки пользовательских историй
В управлении проектами универсальных решений нет. Поэтому всегда важно учитывать нюансы и быть готовыми ко всему.
| ✅ Да | ❌ Но |
|---|---|
| Юзер-стори даёт нам понять, для чего мы делаем конкретный продукт, чтобы не тратить время зря на создание того, что не нужно | Если не следовать правилам написания пользовательской истории, сделать её длинной или абстрактной, то она так и останется в бэклоге |
| С помощью описания функционала глазами пользователя мы упрощаем коммуникацию между заказчиком и командой. Все понимают, для чего мы работаем и что хотим получить в итоге | Юзер-стори нужно дорабатывать и улучшать, пересматривать, обсуждать и проверять на актуальность. Если команда к этому не готова, то мы скатываемся к тому, что в итоге результат может оказаться бесполезным |
| Юзер-стори делает проекты управляемыми, помогает учитывать каждую деталь и улучшать продукт | Если проект крупный и над ним работает большое количество команд, то в пользовательских историях легко запутаться, если нет чёткой структуры эпиков |
| User story помогают удерживать пользователей и привлекать новых | Требуют тщательной проработки, сбора данных, анализа. Концентрация на пользе для пользователя должна быть на уровне заводских настроек в голове, иначе всё может свестись к огромной колонке с техническими заданиями |
Жизненный цикл user story: этапы и роли команды
Создание user story — это цикличный процесс, который проходит через следующие этапы:
создание истории → обсуждение и проработка → оценка → переход в спринт → реализация → тестирование → релиз
Разбираем подробнее.
Создание user story
Менеджер продукта собирает запросы пользователей, анализирует их и фиксирует идею, которую неплохо было бы реализовать.
Аналитику, идеи и варианты проработки удобнее загрузить в документ в Базе знаний и прикрепить его к карточке, чтобы хранить всю информацию по конкретной фиче в одном месте и не терять время на поиск нужной ссылки.
Документ может выглядеть примерно так.
Помним, что его можно доработать в любое время. Если в юзер-стори ну очень много деталей, то можно создать отдельную папку в Базе знаний под неё.
Уточнение и обсуждение user story
Все участники команды, которая будет работать над проектом, собираются вместе и обсуждают историю. Задают вопросы, прорабатывают детали, разрабатывают критерии приёмки. На этом этапе пользовательская история в сыром виде лежит в бэклоге. Результаты договорённостей оформляют в описании карточки или в комментариях, где можно оставлять ссылки на документы или записи разговоров.
Да, мы специально назвали карточку в бэклоге по-другому и отошли от классической структуры, чтобы показать, что это начальный вариант, который будут дорабатывать. На первых этапах обсуждения тоже могут быть сырыми, это норма.
Но в результате все участники рабочего процесса должны понимать, в чём ценность пользовательской истории, как можно её реализовать, с помощью каких инструментов её можно доставить пользователю и как её протестировать.
Оценка истории
Определяем сложность и убеждаемся, что историю реально взять в работу. Напоминаем: в идеале нужно уложиться в один спринт. Это значит, что юзер-стори не должна быть объёмной. Можно оценить конкретную работу в часах, кликнув на поле Оценка времени в карточке задачи.
После того как юзер-стори проработана, оценена и прошла отбор по критериям INVEST, её можно переместить в колонку К работе — то есть в бэклог спринта. Команда разработки потом перенесёт её во В работе, после того как запланирует спринт.
❓Загадка: как связаны юзер-стори и покер?Ответ читай здесь
После детальных обсуждений и оценки работы пользовательская история попадает на обсуждение спринта. Команда берёт её в работу. В карточке уже проставлены дедлайны, теги, приоритеты, назначены исполнители и оценено время работы.
Реализация
Команда приступает к работе — то есть к выполнению технических заданий. В результате должно получиться готовое решение, которое решает задачу пользователя и повышает ценность продукта.
Тестирование и проверка критериев
Карточка с юзер-стори попадает в колонку Тестирование. Тестировщик проверяет, насколько результат соответствует критериям приёмки и есть ли ошибки в коде.
Завершение истории
Карточка попадает в колонку Готово, а пользователь получает функционал, который соответствует его ожиданиям.
В Weeek можно автоматизировать колонки и настроить их так, чтобы карточка с задачей считалась выполненной после попадания в колонку Готово. Для этого нужно: нажать на три точки в названии колонки → выбрать в открывшемся меню Автоматизация → в действии нажать Выполнить задачу → готово.
Карточка станет зачёркнутой автоматически, и появится уведомление.
User story: примеры и антипримеры
Добиваем статью примерами, чтобы тебе точно было всё понятно.
✅ Хороший пример user story для интернет-магазина
История. Как покупатель, я хочу видеть историю заказов, чтобы отслеживать свои покупки.
Критерии приёмки:
- Пользователь может открыть список заказов
- Отображаются дата, статус и сумма
- Можно перейти в детали заказа
❌ Неудачный пример user story для SaaS-сервиса
История. Сделать страницу отчётов.
Критерии приёмки:
- Страница работает
Почему это плохо? Нет пользователя и ценности, из формулировки непонятно, какой должен быть результат.
Как исправить? Как менеджер, я хочу видеть отчёт по продажам, чтобы анализировать эффективность.
✅ Хороший пример user story для мобильного приложения
История. Как пользователь, я хочу получать push-уведомления о новых сообщениях, чтобы не пропускать важную информацию.
Критерии приёмки:
- Уведомления приходят при новом сообщении
- Можно отключить уведомления
❌ Неудачный пример user story для маркетплейса
История. Реализовать фильтры.
Критерии приёмки:
- Фильтры работают
Почему плохо? Слишком общее описание, нет понимания сценария. Скорее всего, «реализовать фильтры» — это больше про эпик, потому что для того, чтобы достичь реализации, нужно сделать огромное количество работы и проработать детали. Одна деталь — одна пользовательская история.
Как исправить? Декомпозировать, проработать сценарии и пользователей.
Собственно, на этом всё. Все, кто читают наш блог, становятся богами планирования по умолчанию 🤓
Подписаться 
