Блог SkillsCup.com

User Story Map – карта пользовательских историй

Пройдите бесплатный курс по Scrum на английском языке и в ответ оставьте 5* и позитивный отзыв udemy.com/course/scrum-guide-roles-events-artifacts/?couponCode=8A75FAC2A5858A507AC8 (если вы в РФ, но необходима регистрация из-под VPN).


Карта историй пользователя

– это визуальное представление пользовательских историй, упорядоченных горизонтально по процессу или этапам, и вертикально по приоритету, и предварительно сгруппированных по итерациям (или спринтам, инкрементам, релизам).

Первые 2–3 уровня подразумеювают разную детализацию:
  • Самый верхний – группы активностей, этапы (опционально).
  • Уровень ниже – шаги, действия пользователя. Они не зависят от реализации, написаны максимально с позиции пользователя.
  • Уровень ниже – может детализировать предыдущий уровень (опционально).
  • Уровень User story, основных "желтых карточек" и задач, которые реализуются за 1 итерацию.

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

Зачем нужна User story map

  1. Чтобы визуально представить создаваемые или уже написанные истории.
  2. Служит структурой при мозговом штурме для генерации новых историй пользователя = при проведении USM-воркшопа.
  3. Показывает контекст и смысловую взаимосвязь историй.
  4. Облегчает декомпозицию больших историй на меньшие.
  5. Помогает планировать – принимать решения о последовательности реализации историй.

Инструкция по созданию USM

Шаг 1. Опишите клиента и желаемую пользу


Портрет пользователя лучше брать не придумывать, а описывать реальных клиентов и реальными потребностями. Для этого предварительно целесообразно:
  1. провести глубинные интервью,
  2. заполнить карту эмпатии Empathy map,
  3. описать  "персоны".

Шаг 2. Опишите крупные шаги процесса

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


Шаг 3. Выберите главные этапы и разделите на несколько

Задавайте себе вопрос:
  • Что можно НЕ автоматизировать, чтобы услугу по-прежнему, хоть и с натяжкой, можно было бы назвать “Получение кредита удаленно онлайн”?

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

На этом этапе неважно, сколько уровней иерархии и постепенных улучшений сервиса получится. Важнее само обсуждение и генерация идей (мозговой штурм). В дальнейшем вы сможете причесать карточки User story, и сформулировать так, чтобы они приносили ценность (Valuable по критериям INVEST).


Шаг 4. Упорядочьте карточки и наметьте релизы

  1. Чем выше в столбце, тем более User story более приоритетна.
  2. Затем распределите между спринтами/итерациями и релизами. Самый чёткий период – следующий. Он содержит минимально необходимый полезный функционал для предоставления услуги. Состав остальных может меняться вслед за меняющимся контекстом.

Шаг 5. Регулярно актуализируйте карту историй

Эту карту не только можно, но и нужно уточнять, дополнять, изменять.



Другие статьи о User story (будут написаны позднее):
  1. User Story – история пользователя
  2. Хорошие User Story соответствуют критериям INVEST
  3. User Story: Способы разделения больших на меньшие
  4. User Story Map – карта пользовательских историй (текущая статья)
  5. В конце спринта (по Скраму) история, как и любой другой элемент бэклога, должна соответствовать Definition of Done – определению готовности
Продукт Agile