Руководство по скраму | 21. Ошибки в истории пользователя

Пользовательские истории описывают, как новая функциональность Продукта работает на повседневном или деловом языке. Однако их подготовка требует много времени, сил и размышлений. В сегодняшней записи мы укажем на самые распространенные ошибки User Story и подскажем, как с ними бороться.

Самые распространенные ошибки User Story — оглавление:

1. Введение
2. Проблемы с 3W
3. Проблемы с 3С
4. Ошибки пользовательской истории — Резюме

Введение

Пользовательская история может быть отличным инструментом для мотивации команды предлагать новые решения проблем, представленных с точки зрения пользователя. О том, что такое User Story, мы писали в отдельной записи. И в этой статье мы представили INVEST — популярный метод написания хороших пользовательских историй. Сегодня мы сосредоточимся на ошибках User Story.

Проблемы с 3W

Правильная User Story отвечает на вопросы:

• Кто? (Кто является целевым пользователем Продукта?)
• Какая? (Какими возможностями обладает Продукт и что он может делать?)
• Почему? (Какой цели это служит?)

Однако ответы на каждый из этих вопросов могут сопровождаться проблемами. Наименее распространенной проблемой является сомнение в том , что должно измениться в продукте в соответствии с потребностями клиента. Поэтому мы сосредоточимся на проблемах, касающихся Кто? и почему?

Кто — личность пользователя

Одна из самых распространенных ошибок при создании пользовательских историй — недостаточно точный ответ на вопрос: для кого? Другими словами, кто является пользователем, для которого запланировано изменение?

Часто общего ответа, указывающего на Заказчика или Конечного пользователя как на получателя изменений, недостаточно. Решение этой проблемы состоит в том, чтобы представить получателя как конкретную персону. Персона — это модельный образ целевого клиента. Другими словами, персона — это представление человека, который будет использовать Продукт определенным образом.

Проанализировав свою пользовательскую историю, вы можете обнаружить, что она одновременно рассказывает истории разных людей. Если целевых пользователей много, стоит подумать о том, чтобы разделить User Story на более мелкие фрагменты , чтобы избежать противоречивых, взаимоисключающих или просто неэффективных действий.

Почему? - плохо сформулированная цель

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

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

Вместо того, чтобы объяснять причину покупки волшебной палочки, эта история пользователя добавляет еще один пункт в список покупок потенциального клиента. Поэтому при подготовке User Story не забывайте о причинах изменения функционала Продукта.

Проблемы с 3С

Мы можем разбить процесс работы с пользовательскими историями на три этапа, называемые 3C:

• Карта — карта, на которой хранится история пользователя.
• Разговор — разговор в Скрам-команде о карточке «История пользователя».
• Подтверждение — определение критериев приемки, подтверждающих, что задача выполнена.

Ошибки могут возникать на любом из них, которые мы опишем ниже.

Открытка

Карта памяти, на которой хранится история пользователя, имеет ограниченную емкость. Поэтому наиболее распространенные проблемы связаны с длиной и объемом User Story. Пользовательская история нуждается в связности и отсутствии хождения вокруг да около, как говорится, до такой степени, чтобы каждое слово имело значение.

Это связано с тем, что проблема карты User Story имеет два измерения. Один из них – формулировка: лаконичная и содержащая необходимый минимум перечисления. Второй — фактический размер пользовательской истории. Одно общее предложение может выразить огромное количество задач, которые невозможно выполнить за один Спринт.

Беседа

Формулировка пользовательской истории в одном предложении является отправной точкой для разговора с командой разработчиков. Поэтому некорректно трактовать его как описание выполняемой задачи. Он отключает возможность переговоров и обсуждения различных способов его реализации. User Story не следует рассматривать как описание требований к функциональности нового продукта, это скорее приглашение начать разговор о конкретных технических решениях, которые приведут к реализации бизнес-ценности, определяемой User Story.

Подтверждение

Мы подробно писали о критериях приемлемости, которые должны быть определены для каждой пользовательской истории, в тексте, описывающем, что такое пользовательская история. Однако одной из распространенных ошибок является отсутствие расплывчатости критериев эффективности.

Хорошо написанная User Story содержит описание ситуации, в которой она реализована. Его проверка заключается в том, что Пользователь использует преимущества новой функциональности, созданной Командой Разработки.

Полезным инструментом для проверки пользовательской истории является разработка приемочного теста. Обычно это находится на другой стороне карты, содержащей User Story.

Ошибки пользовательской истории — Резюме

При подготовке и применении User Stories стоит придерживаться следующих правил:

• Точная идентификация Пользователя , затронутого изменением
• Четко определите цель создания новой функциональности продукта
• Держите объем настолько коротким, насколько это возможно.
• Относитесь к пользовательской истории как к отправной точке для обсуждения решения с командой разработчиков.
• Установите четкие правила принятия

Если вам нравится наш контент, присоединяйтесь к нашему сообществу занятых пчел в Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Руководство по скраму:

1. Глоссарий основных терминов, ролей и понятий
2. Что такое Скрам?
3. Скрам-ценности
4. Как внедрить Scrum в вашей компании?
5. Скрам-команда — что это такое и как она работает?
6. Кто такой владелец продукта?
7. Самые распространенные ошибки владельца продукта
8. Кто такой скрам-мастер?
9. Характеристики хорошего скрам-мастера
10. Самые распространенные ошибки скрам-мастера
11. Какую статистику и показатели должен отслеживать скрам-мастер?
12. Сотрудничество между владельцем продукта и скрам-мастером
13. Команда разработчиков в Scrum
14. Самые распространенные ошибки разработчиков
15. Скрам артефакты
16. Масштабирование Скрама
17. Бэклог спринта
18. Что такое бэклог продукта?
19. Что такое пользовательские истории?
20. Создание лучшей пользовательской истории с INVEST
21. Самые распространенные ошибки User Story
22. Критерии приемлемости пользовательской истории
23. Оценка и баллы в Scrum
24. Планирование покера
25. Игра на оценку команды
26. Определение приращения
27. Скрам-события
28. Что такое спринт в Scrum?
29. Обязательства команды Scrum — цель продукта, цель спринта и определение завершения
30. Что такое диаграмма выгорания?
31. Как создать и интерпретировать диаграмму выгорания?
32. Преимущества и недостатки диаграммы выгорания
33. Канбан-доски в Scrum и Scrumban
34. Скорость в Scrum — скорость команды разработчиков
35. Ежедневный Скрам
36. Планирование спринта
37. Обзор спринта
38. Что такое ретроспектива спринта?
39. Распространенные ошибки во время ретроспективы спринта
40. Развитие бэклога продукта