Руководство по скраму | 19. Пользовательские истории — что это такое?

Пользовательская история — это краткое описание новой функциональности Продукта или ее усовершенствования. Он не содержит технического решения, но отвечает на вопросы, касающиеся функциональности: Кто является пользователем? Что делает Продукт? И какова его цель? Пользовательская история описывает продукт повседневным или деловым языком, хотя она также указывает на задачи Скрам-команды, которые предназначены для повышения производительности команды.

Что такое пользовательские истории? - оглавление:

1. Введение
2. История пользователя. Чья это история?
3. Как использовать пользовательские истории?
4. Критерии приемки
5. Резюме

Введение

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

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

Создание пользовательских историй — задача владельца продукта. На основе беседы с Заказчиком формулирует ответы на вопросы, позволяющие создать User Story и заносит их в Product Backlog. Однако User Stories отражают не только потребности клиентов.

История пользователя. Чья это история?

Скрам-команда создает Историю пользователя, чтобы определить потребности Пользователя, поэтому она изложена на деловом языке. Другими словами, он указывает на преимущества, которые его внедрение принесет пользователю продукта. Однако в Бэклоге Продукта также могут быть Пользовательские Истории, описывающие потребности Команды Разработки, например, улучшение рабочего процесса между Разработчиками, или описывающие потребности Владельца Продукта, например, организация Бэклога Продукта. В таких случаях Пользователь в Пользовательской истории является Разработчиком и Владельцем продукта.

Вы можете описать User Story, ответив на вопросы 3W :

• Кто?
• Делает Что?
• Почему?

Пользовательская история затем содержится в формуле:

Как [тип пользователя] я хочу [что делать?], потому что [почему? Почему?].

Примеры User Stories о функционале интернет-магазина, написанные в такой форме, проиллюстрированы в таблице ниже:

Эта формула позволяет не только сформулировать User Story, но и относительно легко перевести технический язык на деловой и наоборот . В результате и Разработчики, и Заинтересованные стороны ясно видят Цель и этапы ее достижения. Мы также расскажем о создании хороших пользовательских историй с использованием метода INVEST в отдельной статье из серии руководств по Scrum.

Как использовать пользовательские истории?

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

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

Сохранение пользовательских историй таким образом имеет несколько преимуществ, потому что:

• Подчеркивает автономию каждой пользовательской истории — каждая имеет отдельный фреймворк и может выполняться независимо от других.
• Подчеркивает динамику пользовательских историй — порядок их реализации пересматривается Скрам-командой, а текущий порядок реализации виден на доске благодаря физическому расположению карточек с пользовательскими историями.
• Служит напоминанием — благодаря визуальному представлению пользовательских историй у команды Scrum есть указатель, который напоминает им о цели при создании подробных решений.

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

Критерии приемки

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

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

Покупатель может купить волшебную палочку одним щелчком мыши.

Он завершается, когда на странице интернет-магазина появляется работающая кнопка «Купить сейчас» , которая использует информацию об оплате и доставке по умолчанию для вошедшего в систему пользователя.

Резюме

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

Если вам нравится наш контент, присоединяйтесь к нашему сообществу занятых пчел в 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. Развитие бэклога продукта