User Story - что это такое?
Многие сталкивались с термином User Story, но не все могут подробно объяснить его значение, пользу, а главное - когда его стоит использовать.
User Story (пользовательская история) - это короткая формулировка намерения, которое система должна сделать для пользователя. Это ваше личное предположение или исходящее из опроса ползователей.
Предложение для User Story:
Я ___________, хочу _____________, чтобы _____________.
Предложение для User Story:
Я ___________, хочу _____________, чтобы _____________.
Пример: Я ученик школы, хочу послушать музыку, чтобы настроиться на учебу.
К формуле (предложению) выше мы еще вернемся. Сейчас нам это нужно для начального понимания значения, как упаковываются намерения пользователя.
В чем помогает User Story и зачем нужна
- Для описания элементов бэклога
- Для лучшего понимания пользователей (кто они)
- Для описания требования к продукту на понятном для всех языке
- Для вовлечения в процесс разработки пользователей и других заинтересованных лиц
- Для построения User Story Map
Как формулировать User Story
Я специально подготовил небольшую схему, которая максимальна проста для объяснения сути работы с User Story.
- Что это за пользователь? Выясняем, какую он играет роль, что это за тип пользователя, краткий портрет.
- Какое действие пользователь хочет выполнить в продукте или какой результат рассчитывает получить?
- Зачем это ему? Какая в этом ценность? Что пользователь хочет получить?
Теперь для закрепления теории нам нужны примеры
Я посетитель сайта Simha Design, хочу прочитать полезный контент про продукты и дизайн, чтобы улучшить свои навыки в работе над собственным продуктом.
Как покупателю сайта N, мне хочется искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.
Давайте разберем второй пример более подробно.
Предположим, что мы составляем пожелания пользователей и получили примерно такую историю:
Предположим, что мы составляем пожелания пользователей и получили примерно такую историю:
"Как покупателю, мне нужен крупный магазин, в котором я могу купить любую понравившуюся мне книгу".
Согласны, что история получилась слишком расплывчатой и не несет конкретики.
Нам нужно добиться конкретики и оформить в User Story:
Нам нужно добиться конкретики и оформить в User Story:
"Как покупателю сайта N, мне хочется искать книги по жанрам, чтобы быстро найти те, которые я люблю читать".
В итоге, у нас получилось выявить конкретную роль (Actor), одно действие (Action), есть одна ценность, влияние на Actor (Impact).
Обращаю ваше внимание, в User Story нам нужна не просто ценность (Value), а именно влияние от действия (Impact).
Обращаю ваше внимание, в User Story нам нужна не просто ценность (Value), а именно влияние от действия (Impact).
Пример из практики
Разберем следующую пользовательскую историю:
"Как главный бухгалтер сервиса договоров, я формирую отчет по всем договорам, чтобы быстрее принимать решение".
Из этой истории возникает вопрос:
- Как мы понимаем, что пользователь принял решение быстрее
"Как главный бухгалтер сервиса договоров, я формирую отчет по всем договорам в два раза быстрее, чтобы быстрее принимать решение".
Стало лучше и теперь мы понимаем, что на принятие решения может влиять скорость формирование отчета.
Но в чем ценность, что бухгалтер стал формировать отчет быстрее? Правда ли, что это влияет на ускорение процесса принятия решения?
Обратите внимание, что такие вопросы возникают из-за сомнений написанного нами в Impact.
У нас есть много вариантов того, что можно написать после "чтобы…". Нужно помнить, что User Story должна преследовать нашу глобальную цель доработок продукта.
Нам не нужно писать то, во что сами не верим. Другими словами, не пишите влияния (Impact), которых нет и быть не может.
Но в чем ценность, что бухгалтер стал формировать отчет быстрее? Правда ли, что это влияет на ускорение процесса принятия решения?
Обратите внимание, что такие вопросы возникают из-за сомнений написанного нами в Impact.
У нас есть много вариантов того, что можно написать после "чтобы…". Нужно помнить, что User Story должна преследовать нашу глобальную цель доработок продукта.
Нам не нужно писать то, во что сами не верим. Другими словами, не пишите влияния (Impact), которых нет и быть не может.
Поэтому для корректного User Story мы должны себя проверить:
В итоге, если мы понимаем, что наше предположение может помочь достичь глобальную цель, то формулировку влияния (Impact) можно оставить и протестировать историю.
Но в итоге мы доработали историю, чтобы она стала выглядеть следующим образом:
- Составляем Impact Map - это то, что содержит в себе цель, кто и как будет ее достигать, что нужно будет сделать.
- У нас есть глобальная цель (увеличение скорости принятия решений для согласования договоров)
- Мы определили Actor (главный бухгалтер)
- У нас сформулировано предположение (если бухгалтер будет получать отчет по всем договорам быстрее, то это приведет к достижению нашей глобальной цели)
В итоге, если мы понимаем, что наше предположение может помочь достичь глобальную цель, то формулировку влияния (Impact) можно оставить и протестировать историю.
Но в итоге мы доработали историю, чтобы она стала выглядеть следующим образом:
"Как главный бухгалтер сервиса договоров, я формирую отчет по всем договорам всего за 30 секунд, чтобы быстрее принимать решение для их согласования внутри самого отчета".
User Story по критериям "INVEST"
И так плавно мы перешли к критериям:
I - Независимая от других историй, может быть реализована в любом порядке
N - Обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
V - Ценная для клиентов, бизнеса и стейкхолдеров
E - Оцениваемая по сложности и трудозатратам
S - Компактная, может быть сделана командой за одну итерацию
T - Тестируемая, имеет критерии приемки
I - Независимая от других историй, может быть реализована в любом порядке
N - Обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
V - Ценная для клиентов, бизнеса и стейкхолдеров
E - Оцениваемая по сложности и трудозатратам
S - Компактная, может быть сделана командой за одну итерацию
T - Тестируемая, имеет критерии приемки
Когда использовать User Story
- Для выявления ценных функциональностей для разработки
- Когда вы не понимаете кто ваши пользователи и из-за чего они еще с вами
- Для описания портрета пользователя
- Перед запуском рекламы (краткий бриф для отдела маркетинга)
Подведем итоги
- Нам нужно написать много историй, но не громоздких, а четких и понятных всей команде продукта
- Приоритезируйте истории
- Тестируйте истории до начала разработки
- Оценивайте истории
- История - это не задача, а повод для обсуждения и теста. Ее нельзя отправлять в разработку, если не пройден этап CustDev.