User Story Mapping: зачем нужны пользовательские истории и как их правильно писать

В процессе разработки команда может слишком увлечься производственными процессами: вносить логичные, на их взгляд, улучшения в продукт, обновлять функционал, держать курс на потребности бизнеса и монетизацию продукта, но забыть о самом важном — потребностях пользователя. Чтобы создавать востребованные продукты с ориентиром на конечного потребителя, собирают пользовательские карты, одна из таких — user story map.

Карта пользовательских историй или user story map — это маркетинговый инструмент с описанием функциональных возможностей продукта в простой и понятной форме, написанный от имени конечного пользователя. Истории не содержат сложных технических деталей и подробностей реализации продукта. Их основная цель — фокус на удовлетворении потребностей пользователя.

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

Истории помогают команде разработки лучше понять, для кого они создают продукт и сделать его максимально ценным для конечного потребителя.
Если вам требуется определение позиционирования продукта или анализ ценностного предложения — обратитесь в Neogenda. Мы детально проанализируем ваш случай и предложим решение на бесплатной консультации в Zoom.

Далее в статье:

• структура пользовательских историй;
• зачем нужно их составлять;
• преимущества и недостатки инструмента;
• как user story используются в Скрам и Канбан;
• пошаговая инструкция по написанию user story;
• критерии оценки историй.

Структура user story

Любая пользовательская история имеет три важных составляющих:

1. Роль. Описывает роль или тип пользователя, потребность которого требуется реализовать в рамках разработки или создания продукта.Например, «как покупатель», «как администратор», «как гость».
2. Действие. Описывает конкретное действие или функциональность, которую пользователь хочет выполнить или получить от системы.Например, «хочет просмотреть список товаров», «хочет добавить товар в закладки или отложенное».
3. Ценность для пользователя. Указывает на ценность или пользу, которую пользователь получит от выполнения задачи, описанной в user story. Отвечает на вопрос «Зачем это нужно пользователю?» и помогает понять, какой результат ожидается от реализации функции.

Общий шаблон составления юзер стори строится по формуле:

Как кто? (ответ на вопрос «кто пользователь») , я хочу (описание функционала), чтобы (потребность пользователя, которую требуется закрыть)

Пример составления user story с учетом трех составляющих

Зачем нужно составлять пользовательские истории

Создание пользовательских историй решает сразу несколько проблем разработки:

• Формирование единого понимания целей и задач проекта. Пользовательские истории пишутся простым и доступным языком, что помогает всем участникам производственного процесса одинаково понимать требования пользователей к готовому продукту.
• Помощь в подготовке сценариев для тестирования готового продукта или его инкрементов. На основании пользовательских историй могут быть разработаны сценарии для юзабилити-тестирований и тест-кейсы для QA-инженеров.
• Фокус на создании ценности для клиента. Каждая история содержит не только описание самой функции, но и имеет ответ на вопрос «Для чего это нужно пользователю?»
• Подготовка критериев приемки. Пользовательские истории помогают оценить готовность продукта и его соответствие ожиданиям пользователей.
• Проектирование внешнего вида продукта и его отдельных функций. На основании user story можно более точно проектировать интерфейс и создавать дизайн продукта.
• Расстановка приоритетов разработки. При составлении историй можно выделить набор самых важных и нужных функций для пользователей и начать реализацию именно с них.
• Сокращение временных затрат на разработку ненужного функционала. С помощью историй можно сосредоточиться только на ключевых функциях и не тратить время на реализацию маловажного или вовсе ненужного пользователям.

Преимущества и недостатки story mapping

Среди плюсов составления историй можно отметить:

• Истории помогают команде разработки взглянуть на продукт под другим углом, рассматривать его не как набор технических функций и элементов, а как способ удовлетворения потребностей пользователя.
• Изучение историй помогает поддерживать тесную коммуникацию внутри команды, искать и обсуждать свежие идеи по реализации описанных функций.
• Одна история = одна функция. Этот принцип хорошо подходит для scrum- и agile-команд, которые могут использовать истории в качестве цели спринта.
• Простой язык и минимум технических подробностей.

К минусам можно отнести:

• Не всегда точное описание требований. Иногда истории могут быть поверхностными и не содержать достаточной информации для понимания требований.
• Ограничение в детализации. Некоторые важные детали или технические аспекты могут быть упущены в историях из-за ориентации на точку зрения пользователя. Это может затруднить работу команды разработчиков.
• Трудность в оценке и планировании. Пользовательские истории не всегда легко оценить, правильно определить приоритет и сроки выполнения, что может создать трудности в планировании разработки.

Как пользовательские истории используются в Канбан и Скрам

Пользовательские истории как инструмент хорошо вписываются в современные подходы к менеджменту, например, Скрам и Канбан.

В Канбан-методе пользовательские истории могут быть представлены в виде отдельных карточек на доске и пропущены через весь производственный процесс. Каждая история представляет собой конкретный сценарий использования продукта или функциональное требование со стороны пользователя. Карточки помогают отслеживать прогресс реализации каждой user story и осуществлять приемку работы в соответствии с ожиданиями и требованиями пользователей.

Для отслеживания реализации user story в Канбан используют электронные доски, такие как Trello, Jira, Asana, Kaiten, Weeek и другие. Эти инструменты позволяют устанавливать приоритеты для каждой карточки с историей, добавлять подробности и отслеживать прогресс выполнения работ.

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

Для отслеживания пользовательских историй в фреймворке Скрам используются инструменты для управления проектами, такие как Jira, Azure DevOps и другие. С помощью этих инструментов можно создавать и отслеживать реализацию пользовательских историй в рамках проекта.

Чем пользовательские истории отличаются от задач

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

Задача — это конкретное действие, которое разработчики выполняют, чтобы реализовать функциональность, описанную в пользовательской истории. Это шаги или операции, которые необходимо выполнить для создания продукта. Например, задачей может быть добавление кнопки «Купить» на странице товара.

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

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

Если эту историю без каких-либо корректировок сразу добавить к выполнению на канбан-доску, то разработчики обязательно придут с вопросами:

1. Как именно это нужно сделать?
2. Как это должно работать?
3. Какие элементы нужно добавлять?
4. Как это будет редактировать администратор сайта?

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

1. Добавить рядом с выбором размеров кнопку «Таблица размеров».
2. Добавить всплывающее окно с размерной сеткой по нажатию на кнопку «Таблица размеров».
3. Добавить в админпанель поля для редактирования таблицы размеров и т. д.

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

Как написать пользовательскую историю: пошаговая инструкция

Для написания продуманной и качественной истории нужно выполнить несколько шагов.

Шаг 1. Подготовительный анализ

На первом этапе стоит детально изучить проект и сам продукт:

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

Шаг 2. Анализ целевой аудитории

На втором этапе важно выяснить, кто наши пользователи, выявить их потребности и предпочтения, составить портреты.

Среди пользователей стоит выявить несколько основных групп или сегментов.

Шаг 3. Прописать эпики и истории

Эпик в Скраме — это большая история или объем работы, которую невозможно реализовать за один спринт. Эпик, также как и пользовательская история, несет в себе единую цель и ценность для клиента, но в отличие от истории — это целый набор задач, а не описание одной конкретной функции.

Эпики разбиваются на более мелкие истории, которые могут быть взяты в работу и реализованы за один спринт.

Пользователям иногда бывает сложно выделить одну конкретную функцию продукта и им требуется сразу комплекс из нескольких. Собрать такие данные можно в виде эпиков, а их уже разделить на отдельные user story.

Пример эпика:

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

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

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

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

История 3: Как владелец кошки, я хочу иметь возможность поехать с ней на такси, чтобы в экстренной ситуации быстро доехать до ветеринара.

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

Шаг 4. Написать критерии приемки

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

Пример.

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

Критериями приемки могут быть:

• В приложении вызова такси должна быть возможность выбора детского тарифа.
• В приложении должно быть поле с возможностью выбора кресла по возрасту и весу ребенка.
• Водители в своем личном кабинете должны иметь возможность разрешить перевозку пассажиров с детьми.
• Водители должны в личном кабинете указать на какой возраст и вес ребенка у них имеется автокресло.
• Приложение не должно разрешать перевозку детей без выбора автокресла и его размеров.
• Таксисты должны иметь возможность отказаться от перевозки в приложении, выбрав пункт, что пассажир – с ребенком, а выбранный тариф этому не соответствует (выбран обычный, без перевозки детей, не имеющий кресла).
• Поле с выбором кресла должно подсвечиваться и появляться сразу после выбора детского тарифа.

Шаг 5. Расставить приоритеты историй

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

Приоритеты стоит расставлять, учитывая три параметра:

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

Шаг 6. Прописываем задачи для каждой истории

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

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

Шаг 7. Реализация

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

Критерии оценки User Story

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

Аббревиатура INVEST расшифровывается следующим образом:

• Independent (Независимая). Каждая user story должна быть независимой от других историй, чтобы ее можно было реализовать отдельно от других задач и историй.
• Negotiable (Обсуждаемая). История не должна содержать конкретных шагов реализации, она должна быть гибкой и обсуждаемой.
• Valuable (Ценная). История должна быть значимой и приносить реальную ценность бизнесу, пользователям и стейкхолдерам.
• Estimatable (Оцениваемая). История должна быть достаточно четко сформулирована, чтобы можно было оценить затраты по времени и ресурсам на ее реализацию.
• Small (Маленькая). История должна быть достаточно маленькой, чтобы ее можно было реализовать за один спринт или короткое время, сохраняя тем самым непрерывность работы.
• Testable (Тестируемая). История должна быть сформулирована таким образом, чтобы ее можно было протестировать и проверить, достигнута ли описанная цель.

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

Если вам требуется помощь в организации бизнес-процессов продуктовой команды или консалтинг бизнеса — обратитесь в Neogenda. Мы являемся признанными экспертами по современным инструментам менеджмента и точно знаем, как помочь вашему бизнесу достичь результата.

Андрей Сидоренко

Тренер и консультант по OKR. Более 6 лет помогает компаниям разной направленности с внедрением OKR и построением адаптивных процессов. Организатор, продюсер и спикер крупнейших конференций: OKR SUMMIT, OKR Forum, Flow Days, Kanban Eurasia, Agile Days и др.