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-каналу, где мы делимся практиками и опытом.
В статье рассказываю, как применять HADI-цикл (Гипотеза-Действие-Данные-Инсайты), чтобы создавать успешные продукты. Пошаговый разбор этапов, практические советы по работе с гипотезой и внедрению подхода
В статье обсудим, что такое критерии приемки (acceptance criteria) в Agile: зачем нужны, как писать и применять на практике. Разберем отличия от user stories, ключевые принципы и конкретные примеры.
Как быстро понять, сработает ли продуктовая идея и не тратить время вслепую? В статье вы найдете подробный обзор разных типов прототипов, узнаете, как выбрать нужный формат — и начнёте делать продукты, которыми действительно удобно пользоваться.