Что такое story mapping
User Story Mapping – инструкция по применению
Четвертая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
User Story Mapping (USM, карта пользовательских историй) – инструмент целостного проектирования продукта на основе пользовательского пути.
Для чего применяется USM?
Как построить User Story Mapping?
Для построения USM вам потребуется:
Ваша задача — спроектировать по шагам действия пользователя в продукте на основе его реального сценария.
Рассмотрим USM на примере
Магазин цветов решил запустить сайт. Визуализируем опыт клиентов с помощью техники USM.
Обратите внимание, что итоговый приоритет определяется сценарием пользователя. Мы идем слева направо, и только затем по версиям – ведь мы хотим принести больше ценности пользователю. А для пользователя, как правило, ценность тем выше, чем более полно наш продукт закрывает его сценарий.
User Story Mapping – мощный инструмент, позволяющий команде разработки за пару часов взглянуть на бэклог продукта глазами пользователя.
Руководство по сбору требований в формате User Story Mapping: Пользовательская история, 1/3
Инструменты проектирования
Apr 5, 2019 · 9 min read
Что больше всего отличает опытного дизайнера и проектировщика от начинающего, так это способность грамотно «снимать задачу с клиента». Навык этот совокупный, нарабатывается, как и прочие, многократным подходом к снаряду. При этом ни новичок, ни опытный не защищены от ошибок. Хорошая методология помогает их избегать, делая обозримым то, что без неё с трудом влезало в голову.
В этой серии статей я хочу поделиться опытом п рименения наиболее крепкого и полезного, на мой взгляд, метода сбора требований к будущему цифровому продукту. Метод со мной уже девять лет. Работает прекрасно как в заказной, так и в продуктовой разработке. Я провёл сотни часов с заказчиками, записывая требования именно по этой методологии, поэтому в этих статьях содержится не только метод, но и рекомендации как проводить сессии с заказчиком.
Мне есть с чем сравнить. Приходилось писать и пространные ТЗ, и оттачивать запись полезного действия в формате понимания задачи, составлять дотошные сценарии использования, строить UML-диаграммы. С точки зрения выживаемости описанный ниже метод в моей личной практике обошёл все остальные.
Суть метода и его место
Цикл продуктовой разработки состоит примерно из следующих этапов.
Первая фаза с обнаружением продукта чаще всего не заканчивается с началом разработки, и осознание продукта длится на протяжении нескольких, а то и всех циклов его эволюции. Тем, кто работает над проектом, важно разделять общее видение, договорённости о целях, ценностях и способах их достижения. Все эти сведения я буду называть для краткости требованиями.
User Story Mapping, далее USM или сторимаппинг — это метод сбора требований и планирования релизов программного продукта. Он сконцентрирован на пользовательских историях и задачах, связанных с ними.
На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Их важно получить заранее. Хорошо, если предварительно было сделано картирование процессов в форматах Customer Journey Map и/или Service Blueprint.
На выходе: набор задач на проектирование и разработку, привязанных к потоку пользовательских историй.
Метод предлагает фиксировать требования в виде двухмерной карты, где карточки с пользовательскими историями располагаются в хронологическом порядке, а соответствующие им задачи для команды разработки расположены под ними согласно росту глубины проработки. Принципы сбора требований и планирования на основе такой карты описаны ниже, а пока пару слов о том откуда появился метод.
USM пришел из IT-сообщества, развивающего принципы Agile, в ответ на проблему, связанную с трудностями приоритезации и планирования работ над бездной историй. Первая версия метода описана в статье Джеффа Паттона — автора метода, проектировщика интерфейса, а ныне консультанта по работе над продуктами.
Карта историй создаётся преимущественно для нового продукта, продукта, который мы собираемся сделать. Впрочем, карта может быть составлена и для действующего продукта, когда вы хотите его частично или полностью переделать и требуется описать объём имеющейся функциональности.
Структура пользовательской истории
Разберёмся с атомом USM — пользовательской историей. Это одна из нестрогих форм записи функциональных требований к программному обеспечению.
Классически история записывается на самоклейку Post-it, чтобы не быть сложносочинённой — размеры бумажного формата помогают не растечься мыслью по древу. Запись ведётся в процессе беседы команды со всеми важными стейкхолдерами. Чтобы избежать фантазий проектировщиков и разработчиков, все участники беседы должны прийти к соглашению, что зафиксированная история отвечает целям и интересам всех стейкхолдеров.
До появления пользовательских историй использовался формат сценариев использования (Use Cases). К сожалению такие сценарии, лишены эмпатии к человеку, для которого создаётся программа. В сценариях использования его обычно называли презрительным и обезличенным «юзером». Чтобы исправить эту ситуацию апологеты гуманности в парадигме User Centered Design сместили акцент на роль человеческого фактора. Появился метод персон, помогающий создать модели групп будущих пользователей и хоть как-то передать команде разработки понимание целей, задач и чаяний людей, для которых создаётся продукт.
Любая пользовательская истории записывается для персоны или функциональной роли в системе. Самый просто пример двух различных функциональных ролей: продавец и покупатель. Иногда несколько ролей могут объединяться в одном человеке.
Не стану приводить в этой статье примеры персон и способов их создания на эту тему написано достаточно. К тому же, насколько могу судить из опыта сообщества и собственного, персоны трудны в создании и валидации, они содержат множество лишних предположений. Мы, в Byndyusoft, преимущественно используем функциональные роли при записи историй. Далее буду обозначать субъекта истории действующим лицом — под ним может пониматься как персона так и функциональная роль.
Классический шаблон
Вернёмся к историям. Классическим форматом является следующий:
Действующее лицо, способ достижения, ценность
Важно понимать для какого действующего лица записывается история. Обычно действующее лицо «выносят за скобку», чтобы не повторять его в каждой карточке. Для этого над историями вешают карточку с изображением функциональной роли или персоны и подписью.
Истории, записываемая для понятной всем роли или персоны, состоит из двух частей: ценности и способа её достижения.
Самая важная часть истории — ценностная. «Я как такой-то хочу сделать то-то, чтобы что?». Последняя часть рисует образ полезного действия, достигаемого в истории. Полезное действие помогает увидеть главную цель действующего лица, и направляет проектировщика на способы достижения этой цели.
Без ценности в историю можно записать любую ерунду, и это не будет заметно. Ценность — как лакмусовая бумажка для истории. Пока записываешь ценность, несколько раз переформулируешь и всю историю.
Например, кто-то формулирует историю как-то так.
Образа решения не возникает, видение ситуации не передано. Почему здесь важна мгновенность? На этот вопрос нужно получить ответ в процессе сбора требований и записать его в виде ценности в историю. Например, выяснится, что заказ могут передать другому продавцу, если вовремя не отреагировать. Тогда впору записать историю так:
Если вопрос «зачем мгновенность» оставить без ответа, история будет содержать скрытый риск, который весьма вероятно увеличит количество итераций переделки. Лучше выяснить это до начала проектирования и разработки, иначе у вас история с миной замедленного действия:
Избегание излишних ограничивающих подробностей
Часть с описанием способа достижения полезного действия наиболее вариативна. Здесь в запись историй прокрадывается дизайн. Фиксируя определенный образ достижения полезного действия, мы постулируем один из вариантов работы системы. Важно это понимать и не привносить в историю излишне жестких ограничений. Ограничения важны для проектирования, однако лишние ограничения, возникшие из фантазий, отсекут хорошие решения. Излишняя детализация здесь возникает из-за того, что людям проще мыслить готовыми решениями. Пользователи будущей системы и стейкхолдеры выдают на-гора конкретные варианты того как именно должно быть исполнена история. Важно уйти от излишней конкретики и записать историю без подробностей реализации.
Чтобы избежать лишних подробностей и ограничений на уровне языка интерфейса, рекомендуется избегать названий интерфейсных элементов и паттернов в тексте историй.
Ниже плохой вариант истории:
Плохой, потому что содержит излишнее ограничение на уровне подходов в реализации: пуш-уведомление — это конкретный приём подачи сообщения на мобильных устройствах.
Выбор конкретных способов реализации зависит от имеющихся технологических и временных ресурсов. Лучше записать ту же историю более обще:
Предъявление и изменение данных — вот и весь ваш хвалённый IT
С точки зрения технических систем, любой интерфейс — это трансмиссия — то, что передаёт информацию от передатчика к получателю и обратно.
Я заметил, что все истории в разработке программного обеспечения распадаются на два класса. Все они про предъявление данных и манипуляцию ими. Мы либо что-то показываем, либо влияем каким-то образом на систему, либо делаем и то, и другое.
Исходя их вышесказанного, чаще всего одни и те же слова попадают в запись историй. Вот примеры глаголов, которые мы чаще всего используем в записи историй:
У каждого проектировщика или команды может сложиться свой набор.
Полезные форматы историй
При записи историй удобно придерживаться шаблонов. Это помогает не упустить важного и окупается когда вы, зная форматы, расходуете меньше внимания на поиск того как записать только что озвученное. Особенно это важно, если вы только начинаете использовать картирование историй для сбора требований. Вот несколько форматов, которые показали себя хорошо на практике.
Классический укороченный
В этом шаблоне как и во всех остальных далее действующее лицо вынесено за пределы карточки. В формате также опущен глагол «хочу», записывается сразу действие и ценность.
Вопросы и утверждения
Большинство историй на демонстрацию и изменение данных будет казаться неуклюжими для записи в классической форме из-за того, что записываемая ценность кажется самоочевидной. Если записывать по классике, получается масло-масленное:
В этих случаях хорошо себя показали истории-вопросы и истории утверждения. Пару примеров историй-вопросов:
Здесь ценность очевидна, а суть истории в том, что человек получает ответ на волновавший его вопрос.
Для сравнения ниже одна и та же история в классическом формате и формате истории-вопроса:
То же самое относится и к историям про модификацию данных. Для простоты записи мы иногда используем такую форму утверждения:
Истории про изменение
Зачастую ценность описать проще, если показать два состояния системы: текущее с проблемой и новое — лишенное проблемы. В этом случае пригождается формат историй на изменение:
Историю про рекламодателя можно переписать в формате изменения:
Этот формат истории легко запомнить, представляя схему перехода от вреда к пользе: Бесконтрольные траты (вред) → расходы только на выбранные тематики (польза).
Критерии готовности истории
Как понять, что история закончена? Я смотрю на следующие индикаторы.
Как понять, что история спланирована или реализована полностью в определенной версии программного продукта? Здесь есть два способа. По одному из них на обороте стикера с историей записывают перечень критериев её готовности (Definition of Done). Другой — фиксировать все подробности отдельными карточки с детальными задачами под историей. Достижение полноты проверяется по этому перечню или набору карточек.
Как построить карту историй (user story mapping), если проект уже в работе
Копирайтер, переводчик и редактор. Опыт работы над федеральными (USABILITYLAB/AIC) и международными проектами (iSpring). Преподаватель курса «Копирайтинг и контент-маркетинг» в Институте программных систем.
Авг 12, 2018 · 6 мин читать
Скорее всего вы думаете: “Проект уже запущен, неужели нужно все начинать сначала? И выбросить на ветер всю проделанную работу?” И вот вы все размышляете, как story mapping мог бы усилить ваш проект, и стоит ли оно того…
Что ж, ребята, хорошие новости! Даже если ваш проект уже в работе, вы все еще можете воспользоваться методом story mapping. Честно. Конечно, придется поработать, но оно того стоит.
Шаг 1. Строим карту (story map)
Начните с того, что имеете
Для начала, соберите в кучу те пользовательские истории, которые у вас уже есть. Изучите истории, над которыми сейчас работают другие команды и поместите их на свою доску. Только пообещайте, что не будете воровать у них карточки: перепишите все по-честному на новые карточки.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Если вы используете JIRA, VSTS/TFS или какой-то другой инструмент, просто распечатайте все свои тикеты. Да, даже закрытые (поймете, зачем они нужны, когда мы дойдем до шага “Заполнить пробелы”).
Далее, нужно рассортировать истории по группам, чтобы при необходимости вы быстро могли найти нужную. Не очень-то удобно перебирать стопку из 150 карточек в поисках той самой истории.
Сразу предупреждаю: пользовательские истории обычно бывают фичами/существительными, а нам для построения карты историй нужны глаголы/действия/шаги. Поэтому не стоит брать за основу существующий бэклог: лучше начать с создания простейшей карты пути пользователя.
Создайте карту пути пользователя (journey map)
Эта карта (journey map) будет скелетом карты историй (story map). Вам будет проще, если вы начнете работать с укрупненной картой пути пользователя, пока не вдаваясь в детали. Наша первая цель — наметить общий маршрут.
Возьмите пачку стикеров, маркер и изоленту и забейте кусок стены. Для начала спросите себя: какой путь проходит пользователь в продукте? С чего он начинает? Самый простой подход — взять за основу путь основного персонажа. Каждый шаг пути мы будем писать на отдельном стикере.
Используйте существующие тикеты
Если вам встретятся какие-то шаги, которые уже есть в карточках пользовательских историй, не дублируйте их на стикерах, а просто приклейте карточки на скотч. Возможно, большинство шагов у вас уже есть. Если так, круто.
Вот так будет выглядеть ваша карта. Белые карточки — это распечатанные пользовательские истории из физического бэклога или из JIRА. Цветные квадратики — это новые стикеры.
Заполните пробелы
Скорее всего вы обнаружите пробелы в вашей карте историй. Или может оказаться, что вы упустили некоторые важные действия, шаги или мелочи, которые любят всплывать перед самым релизом.
Тут-то и происходит все волшебство. Проблема бэклога на 150 тикетов в том, что все они разные по размеру и очередности. Здесь мы берем за основу 150 историй и равномерно распределяем по пути пользователя. С таким подходом легко обнаруживаются проблемные места. Вещи, которые мы считали никак не связанными, на самом деле оказываются взаимозависимыми. Мы обнаруживаем небольшие истории, которые можно объединить и легко закрыть в пределах одного спринта — и создать полезную фичу.
Как только соберете всю карту, начните искать темы, или, как мы называем их, “действия”. Это такие большие задачи, которые может осуществить пользователь и которые могут включать множество шагов. Сюда относятся такие крупные вещи, как “управлять письмом” или “обновить”.
Определите состав “релиза”
Да, релиз в кавычках. Все потому, что мы хотим разделить планирование и релизы. Слово “релиз” — это просто понятие, которое я использую чтобы разграничить интервалы планирования. Можете называть это “маркетинговыми релизами” или точками отсчета. Это не обязательно физические релизы. Вы можете постоянно совершенствовать продукт и копить “релизы”, а потом выпустить все большим блоком. Или вы можете потихонечку, без огласки выпускать мелкие улучшения и постепенно тестировать их на пользователях. Не важно какой вариант вы выберете, главное, чтобы он подходил вам и команде.
Итак, для начала убедимся, что этапы по каждому шагу расставлены по приоритету: маст-хэв опции должны быть сверху, а приятные мелочи — снизу. Затем возьмите изоленту и разметьте, какие этапы войдут в состав первого “релиза”.
Если вам кажется, что в таком виде ничего не понятно, можно провести изолентой прямую линию и разместить все, что не вошло в первый релиз, под линию. Примерно так:
Шаг 2. Упорядочиваем хаос
Очень важно правильно организовать карту, чтобы вы могли ее читать. Просто слова на стене выглядят слишком хаотично. Нужно, чтобы на основании карты вы могли рассказать простую историю, вдаваясь в детали только при необходимости, если это важно.
Эпик vs. История vs. Задача
Итак, действия в верхнем ряду считаются эпиками, “шаги” — историями, а то, что ниже — задачами? Или верхний ряд это что-то еще, а шаги — это эпики, а опции — истории? Короче, это не важно. Делайте так, как удобно вашей команде и как правильнее для вашего продукта. Если “шаги” можно завершить в рамках одного спринта, то они ближе к историям. А если они огромные и могут растянуться на 2-3 спринта — то это скорее эпики. Повторюсь, делайте так, как лучше вашей команде.
Цветовое кодирование персонажей
Цветовое кодирование пригодится, если вы разрабатываете продукт под разные сегменты пользователей или под разных персонажей. К примеру, вы создаете решения под веб, мобильные устройства и обращения по телефону. Цветные стикеры помогут внести ясность и сегментировать карту, как на рисунке ниже. На распечатанных тикетах можно ставить цветные точки. Не забудьте добавить легенду, чтобы ваша система кодирования была понятна всем и сразу.
Поддерживаем актуальность карты
Как и все в этом мире, карта со временем теряет актуальность. Нужно обновлять вашу карту историй на протяжении всего проекта. Когда вам в голову придут новые шаги и детали, добавляйте их на карту, обновляйте приоритеты, показывайте прогресс. Отличный способ продемонстрировать прогресс — отмечать сделанные карточки яркой галочкой.
Ну, вот и все. Несколько простых шагов — и вы превратили переполненный бэклог в живой ресурс, по которому ваша команда и все заинтересованные лица могут отслеживать развитие проекта. И все это мы сделали, когда проект был уже в работе! Надеюсь, это поможет вам и вашей команде создать более качественный продукт и реализовать правильные функции — на каком этапе работы вы бы ни находились.
Что такое story mapping
Создание карт пользовательских историй в Agile-проектах
Аудио перевод статьи
Карты пользовательских историй помогают Agile-командам определять приоритетные элементы для разработки, а также визуально отображать, как отдельные составляющие продукта сочетаются друг с другом. Они направляют итеративный процесс разработки продукта и помогают учитывать интересы пользователей при обсуждении идей, а также расставлять характеристики продукта в приоритетном порядке.
Однако такой подход чаще всего не слишком эффективен. Чтобы тщательно изучить документы, необходимо время, которого зачастую и так не хватает. Даже те члены команды, которые прочитали их от начала до конца, скорее всего, получат совершенно разное представление о том, что им следует разрабатывать. Вместо того, чтобы способствовать повышению продуктивности команды, сложная для восприятия документация изначально подавляет творчество, мешает коммуникации и взаимодействию, а также препятствует креативному мышлению. В таком случае более эффективной альтернативой являются карты пользовательских историй — это упрощенное представление цифрового продукта, созданием которого занимается Agile-команда.
1. Что такое карты пользовательских историй
Определение: Карты пользовательских историй (также известные как карты историй) — это метод бережливого UX для описания пути пользователя, популярный среди Agile-команд. Данный метод предполагает использование стикеров для обозначения ожидаемых взаимодействий пользователя с цифровым продуктом в процессе достижения его целей.
Данный метод получил свою известность благодаря Джеффу Паттону. Карты пользовательских историй способны заменить длительный процесс составления списка технических требований и этапов доработки продукта, требующих особого, характерных для каскадной модели разработки. Карты историй стимулируют взаимодействие между членами Agile-команды, а также позволяют им увидеть более полную картину того, как функционирует цифровой продукт в целом и как его элементы сочетаются друг с другом. Последнее особенно важно в Agile-проектах, поскольку потеря общего представления о продукте — распространенная проблема, возникающая в командах, которые работают со списком отдельных пользовательских историй.
Карта пользовательской истории отображает 3 типа действий разной степени детализации: действия (в общем смысле), шаги и детали (конкретные действия). Действия и шаги пользователя отображаются горизонтально в верхней части карты, а детали — вертикально, под соответствующими шагами в приоритетном порядке. Чтобы показать каждый уровень карты истории, мы будем использовать в качестве примера функцию депонирования чеков (внесение средств с чека на счет) в мобильном приложении.
2. Почему карты пользовательских историй называются именно так
Пользовательские истории представляют собой сформулированные простым языком описания функций, элементов пользовательского интерфейса или задач. Это необходимо для того, чтобы члены команды могли обсудить друг с другом возможные решения, учитывая потребности конечных пользователей и выгоды, которые они могут получить. Подобные обсуждения помогают добиться общего понимания в команде намного быстрее, чем чтение документации, которая содержит требования к продукту. Пользовательские истории могут быть как общими (описывают продукт или какую-то функцию целиком), так и более конкретными (относятся к определенному элементу интерфейса). Например:
Agile-команды обычно создают краткие, но ценные пользовательские истории и используют их, чтобы спланировать и определить приоритеты для работы в каждом спринте. В карте пользовательской истории действия, шаги и детали обозначаются с помощью коротких, точных глагольных словосочетаний. На их основе создается первая половина пользовательской истории, в которой описывается то, какие потребности есть у пользователя и что он хочет сделать. Затем история может быть расширена за счет добавления ключевых преимуществ, которые составляют вторую ее часть. Таким образом, данный инструмент получил название “карта пользовательских историй” за счет того, что он позволяет преобразовывать глагольные словосочетания, записанные на карте, в настоящие подробные пользовательские истории, которые могут стать предметом дальнейшего обсуждения. В конце концов они будут снабжены критериями приемки и добавлены в перечень работ по продукту для определения приоритетности и оценки важности.
3. Как и когда создаются карты пользовательских историй
Карты историй можно использовать на любом этапе процесса разработки продукта, чтобы стимулировать обсуждение и выработать у команды единое понимание. Можно создать карту истории сразу после проведения первичных исследований, чтобы отобразить опыт взаимодействия пользователя с новым продуктом, а если продукт уже существует, то необходимо проведение юзабилити-тестирования. В любом случае карта историй показывает решения проблем, выявленных в ходе исследований. После создания карты историй команды будут продолжать работу и обращаться к ней: добавлять в нее пункты, а также менять карту таким образом, чтобы она отражала текущее состояние продукта и позволяла определить, над чем работать и что выпускать в последующих спринтах.
Карты историй наиболее эффективно создавать небольшой командой, в которой представители продукта, UX-специалисты, разработчики и тестировщики работают вместе, сообща обсуждая и разрабатывая план продукта. Перед началом работы важно обсудить следующие моменты:
При создании карты историй команды, работающие в одном помещении, используют стикеры и специальные доски. В то время как специалисты, работающие удаленно, могут воспользоваться видеосвязью, цифровыми таблицами с возможностью совместной работы, онлайн-презентациями или веб-приложениями. В работе над картой должен принимать участие каждый сотрудник.
Обозначьте каждый вид действий стикерами определенного цвета (реальными или виртуальными), чтобы карта историй выглядела организованно. Важно сформулировать действия, шаги и детали таким образом, чтобы они отражали то, чем занят пользователь в конкретный момент времени в ходе взаимодействия с продуктом. Например, если бы вы создавали цифровой продукт, использующий искусственный интеллект и машинное обучение, шаг в карте истории был бы обозначен как “Поделиться предпочтениями”, а не “Обучить искусственный интеллект”.
4. Карты пользовательских историй или карты пути клиента
Когда идет речь о картах пользовательских историй многие задаются вопросом, чем этот инструмент отличается от карты пути клиента. Ключевые различия заключаются в том, что при создании карт используются разные подходы, и каждая из них имеет свое назначение. Карта пути клиента определяет точку зрения пользователя, показывая шаги, которые он проходит для достижения цели, описывает его мысли, эмоции, каналы взаимодействия и устройства, которые он использует на этом пути.
Карта пользовательской истории подходит к вопросу с точки зрения продукта. Ее предназначение — направлять процесс планирования, внедрение характеристик и функций продукта для решения проблем пользователей. Проще говоря, карта пользовательской истории связывает те особенности, которые мы выявляем при составлении карты пути клиента, с теми решениями, которые мы собираемся реализовать в создаваемом продукте. Кроме того, она включает в себя общие идеи и возможности, возникающие в ходе работы над продуктом.
Если добавить в карту пути пользователя действия, шаги и детали, то она может легко превратиться в карту пользовательской истории. Точно так же карта пользовательской истории трансформируется в карту пути клиента, когда в нее добавлены контекст, мысли и чувства пользователей. Эти два типа карт могут эффективно применяться как вместе, так и по отдельности, ведь используемые для их создания методы исследования зачастую одинаковы.
5. Карты пользовательских историй в Agile
Карты пользовательских историй делают Agile-разработку более эффективной по нескольким причинам:
Заключение
Карты историй побуждают членов команды к продуктивным, ориентированным на интересы пользователей дискуссиям о создании продукта, делают идеи для бэклога более наглядными и позволяют командам увидеть общую картину. Если все сделано правильно, карты пользовательских историй помогают выявить логические и готовые к выпуску инкременты продукта (промежуточные результаты), которые соответствуют потребностям пользователей. Они также позволяют увидеть возможные последствия и области риска еще до начала разработки. Такой подход позволяет командам уже на ранних этапах иметь понимание того, что работает, а что нет. Опытные команды используют полученные знания, чтобы принимать решения о том, на каких задачах стоит сосредоточиться, чтобы максимально повысить удобство использования и ценность продукта.
И, наконец, самое главное: поскольку идея Agile заключается в том, чтобы принимать изменения и реагировать на них, а не следовать конкретному плану, карты историй способствуют более эффективной адаптации. Ведь намного проще заменить несколько стикеров, чем переписывать объемную документацию с требованиями к продукту и процессу его разработки.