User story: пора применять правильно

User story (пользовательская история) считается одним из самых простых способов описания бизнес-требований. Многие считают именно user story главным инструментом для продакт-менеджера: это помогает ему простыми словами объяснить разработчикам, что и зачем должно быть сделано.

Обманчивая простота

На курсах продуктового менеджмента про user story обычно рассказывают так: «Это очень просто — пишите, кто вы, что вы хотите и как вы будете это использовать». И начинающие продуктовые менеджеры начинают думать, что это действительно так легко и не требует более глубокого погружения в детали.

Шаблон для пользовательской истории выглядит так:

Пользователь хочет … для того, чтобы …

• Охранник хочет купить квадроцикл, чтобы охотиться в Тайге.
• Молодой человек хочет купить квадроцикл, чтобы участвовать в ралли.

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

На этом этапе начинающие продакты устраивают праздник. Для них обучение закончено, они идут ставить первые задачи команде. Команда в шоке.

Примеры неудачных user story

Пример 1

Как оператор колл-центра я хочу, чтобы по отменённым заказам в CRM передавался признак declined по интерфейсу 139.

Разберём ошибки:

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

б) По такой истории разработчик будет пытаться передать статус именно по 139 интерфейсу. Правильно ли это с точки зрения архитектуры? Нет ли другого интерфейса, который уже передаёт нужную информацию? Этого продуктовый менеджер не знает. Оставьте технические детали на усмотрение специалистов, они могут предложить решение лучше.

Пример 2

Как владелец сайта я хочу добавить на карточку товара красную кнопку «Купить», чтобы повысить конверсию.

Ошибки:

а) Что должно происходить при нажатии кнопки? Куда она ведёт?

б) «Чтобы повысить конверсию» — это не описание ожидаемого результата. Тем более повышать конверсию можно разными способами. Лучше написать «чтобы при нажатии пользователь попадал на экран оформления заказа». История должна отражать сценарий использования.

в) Добавить кнопку вместо имеющейся? Или на карточке должно быть две кнопки? Это уже придирка, но об этом тоже было бы неплохо подумать при формулировке user story.

Пример 3

Как маркетолог я хочу добавлять к каждой покупке подарок, чтобы повысить лояльность клиентов.

К этой истории есть один комментарий, но он очень важный: А не проще ли передать это требование складу в виде инструкции или распоряжения и отправить им подарки, предназначенные для вложения в заказ? История выглядит так, будто разработка не нужна совсем.

Смысл и назначение user story

Ещё Майк Кон, известный во всём мире agile-коуч, говорил, что «пользовательские истории — это не конечные требования к системе, они не предназначены быть полезными в конце итерации» (в книге “User stories applied“). В первую очередь, пользовательские истории нужны для того, чтобы выяснить, что нужно клиенту. Так ищутся основные боли пользователя и возможные способы их исправления.

Следующий этап — обсуждение каждой истории с заказчиком. На этом этапе каждая история детализируется до уровня, который позволит описать верхнеуровневые требования к системе. И после этого этапа для каждой истории появляется Definition of Done — критерии готовности, по которым можно понять, что требование выполнено.

Итак, три этапа:

1. Пишем истории.
2. Обсуждаем и детализируем истории.
3. Определяем критерии готовности.
4. При необходимости повторяем пункты 2-3 ещё несколько раз.

Проверка user story

И даже после нескольких таких итераций пользовательские истории могут нуждаться в улучшении. Проверить это можно с помощью метода INVEST:

• I (Independent) — ваша история не зависит от выполнения других историй.
• N (Negotiable) — вы уже несколько раз обсудили историю.
• V (Valuable) — реализованная история принесёт реальную бизнес-ценность.
• E (Estimable) — возможно оценить трудозатраты, необходимые для выполнения истории.
• S (Small) — историю можно реализовать за одну итерацию.
• T (Testable) — есть понятные критерии приёмки и тестовые сценарии для проверки реализации.

Пример хороших user stories

Пример 1

Как куратор онлайн-курса я хочу знать имя и контакты заинтересовавшихся курсом посетителей сайта, чтобы направить им по email информацию о старте курса.

Пример 2

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

Что может пойти не так

1. Вы написали лучшую пользовательскую историю за всю вашу карьеру, она отвечает принципам INVEST, уже готовы сценарии тестирования. И в этот момент у заказчика меняются требования. Если вы оставите историю без изменений, она может не принести пользы. Не бойтесь вносить корректировки даже в идеальную user story.
2. Ваша история написана хорошо, но понятна только вам и заказчику из-за использований специфических терминов, аббревиатур и сокращений. Или наоборот, после обсуждения с командой разработки появилось слишком много технической информации, которую уже не понимает заказчик. Помните, что история должна быть понятна всем.
3. После детализации истории она занимает лист А4. Вы уверены, что вся информация необходима? История не должна занимать всю вашу доску с требованиями к продукту.
4. Все истории понятны и достаточно детализированы, но описывают сценарии использования только для одного типа пользователей. Вспомните всех, кто будет пользоваться продуктом и на кого повлияет ваш продукт.
5. Ваших историй слишком много в бэклоге, в них уже сложно ориентироваться. Старайтесь поддерживать бэклог в актуальном состоянии, вычёркивайте ненужные истории (и удаляйте их из jira/trello/etc.). Поставьте своё ограничение на общее количество пользовательских историй и соблюдайте его. Идеального числа нет, экспериментируйте.
6. Вы переносите ваши истории из бэклога продукта в бэклог спринта без изменений. Помните, что для бэклога спринта каждую user story необходимо разбить на подзадачи, понятные для разработчиков. Это зона ответственности scrum-мастера, IT проджекта, архитектора или кросс-системного аналитика, в зависимости от распределения ролей в вашей компании. Подзадачи должны быть максимально чёткими и понятными для исполнителя.
7. Ваш спринт целиком состоит из задач по реализации пользовательских историй. Оставляйте время для устранения багов и технического долга, чтобы не копить проблемы.
8. Команда уже реализовала половину историй, а владелец продукта не провёл приёмку ни одной. Прогресс спринта зависит от приёмки задач, не затягивайте с этим этапом. Поздняя приёмка не оставляет времени на исправление ошибок, из-за этого будет расти список задач на следующие спринты, а общее количество выполненных задач при этом не изменится.

Выводы:

1. Поймите, чего хочет пользователь. Обсудите и детализируйте каждое требование.
2. Опишите сценарий использования в формате user story с соблюдением принципа INVEST.
3. Удостоверьтесь, что история понятна и заказчику, и исполнителям.
4. Самые приоритетные истории разбейте на подзадачи и включите в ближайший спринт.
5. Наименее ценные истории удалите из бэклога продукта.
6. Организуйте приёмку выполненных историй на протяжении всего спринта.