User Story — инструкция по применению
Как правильно формулировать пользовательские истории? Третья статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT
User Story (пользовательская история) — короткая формулировка намерения пользователя и того, что продукт должен сделать для него.
Для чего применяется User Story?
- Для описания элементов бэклога
- Для лучшего понимания пользователей
- Для описания требований к продукту на понятном для всех языке: пользователей, разработчиков другие заинтересованных лиц
- Для вовлечения в процесс разработки пользователей и заинтересованных лиц
- Для построения User Story Mapping
Как формулировать User Story?
User Story — это ответы на 3 вопроса, связанные в одно предложение:
- Что это за пользователь?
- Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
- Зачем это ему?
Как <роль или тип пользователя>,
я хочу/могу <выполнить действие или получить результат>,
чтобы <получить ценность>
Еще 50 инструментов для владельца продуктаОписания продуктовых практик и подходов, сгруппированные по 7 темам, от Дмитрия Кустова
Темы: анализ рынка, сегментация, описание и исследование клиентов, проектирование решений, управление бэклогом, управление продуктом, метрики.
Примеры пользовательских историй
И ещё немного примеров:
Как <пользователь соцсети>, хочу <видеть в ленте только позитивные посты>, чтобы <не портить себе настроение>
Как <гипертоник>, я хочу <нормализовать давление на весь день>, чтобы <не измерять его в течение дня>
Как видно из примеров, ценность User Story как инструмента в том, что он очень универсален — вы можете использовать для лучшего понимания пользователей в абсолютно любой сфере.
Хорошая пользовательская история
INVEST — критерий хорошей истории:
Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке
Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
Valuable — ценная для клиентов, бизнеса и стейкхолдеров
Estimable — оцениваемая по сложности и трудозатратам
Small — компактная, может быть сделана командой за одну итерацию
Testable — тестируемая, имеет критерии приемки
Эти критерии не всегда достижимы, но чем больше историй будут им удовлетворять, тем более гибким будет ваш процесс разработки продукта.
Мы учим формулировать User Story на тренинге «Владелец продукта: краткий курс выживания».
P.S.: Серию статей про продуктовые инструменты Роман Баранов и Дмитрий Кустов пишут, используя технику pair writing.
Подключайтесь к Telegram-каналу, где Дмитрий делится практиками и опытом.
Разработка — это дорого и очень часто ее ресурсов не хватает, особенно в небольших компаниях. Именно поэтому в организации критично важно передавать команде разработки только действительно важные и актуальные задачи. Как понять, что бизнес-идея жизнеспособна? И какие быстрые и недорогие эксперименты помогут оценить потенциальные риски новой гипотезы?
В статье Иван Дубровин рассказывает, как выстроить стратегию тестирования бизнес-идеи до этапа разработки.
Заключительная часть цикла из 4-х статей про менеджера продукта и владельца продукта, которая поможет вам понять ландшафт продуктового менеджмента.
Lean Canvas на примере: как построить и как использовать для формирования продуктового видения. Пятая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.