Практика Scrum: как создать бэклог продукта 💎 — OnAgile Consulting

Практика Scrum: как создать бэклог продукта

Пошаговый алгоритм создания бэклога продукта для Scrum-команд.

Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Прежде чем Scrum-команда приступит к работе в первом спринте, нужно создать бэклог продукта. Бэклог — это полный список всех требований (пользовательских историй) к продукту. Чем качественнее он подготовлен, тем эффективнее будет работа команды в спринте.

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

Дорожная карта продукта

В случае продуктов, хорошо известных пользователям, и больших компаний наполнять элементами бэклог продукта будет проще, если предварительно сформировать видение и высокоуровневый план развития продукта — дорожную карту (Product Roadmap). 

Это необязательный этап: стартапы и инновационные продукты, у которых нет аналога на рынке, на начальном этапе в дорожной карте не нуждаются — в этих случаях стоит начать с пользовательских историй (User Story).

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

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

Работа по Scrum не отрицает постановку долгосрочных целей, однако при наполнении бэклога наиболее подробно следует проработать элементы, которые войдут в первые 1-2 спринта. Элементы для последующих спринтов можно описывать с меньшей степенью детализации — скорее всего, они потребуют доработки с учетом обратной связи.

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

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

При создании пользовательских историй следует учитывать разные группы пользователей. История обычно строится по принципу «действие и причина»:

как ____, я хочу ____, чтобы ____.

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

Приоритизация

Итак, бэклог наполнен элементами. Теперь пришло время разобраться, сколько усилий потребует выполнение каждого из них (провести оценку трудоемкости) и какие элементы следует взять в работу в первую очередь. Это непростая аналитическая задача, решение которой облегчают инструменты вроде WSJF — об этой методике мы подробно рассказывали в материале «Модель приоритизации бэклога WSJF»

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

Критерии готовности

Прежде чем приступать к работе, важно определить, как команда в процессе работы поймет, что элемент бэклога полностью реализован. Для этого разрабатываются стандартизированные критерии готовности (Definition of Done, DoD), которые гарантируют, что вся команда понимает, какой результат ожидается от выполняемой ими работы.

Хотите узнать, каких результатов можно достичь с помощью Agile в вашем проекте или компании?
Напишите нам
                                                      
Опубликовано

Ближайшие тренинги по Agile и Scrum

Еще публикации по Agile в Управление продуктами

Публикация
Промышленность
Проектирование продукта: пример сильных вопросов для Customer Development
Проектируя новые продукты, мы фокусируемся на изучении потребностей будущих потребителей. Один из лучших инструментов для понимания потенциального клиента — интервьюирование.
Публикация
Разработка ПО
Подборка книг о проектировании и запуске прорывных продуктов
Эта подборка книг — для тех, кто связан с проектированием, запуском и развитием продуктов в компаниях.
Публикация
Управление продуктами
Lean Customer Development, или Бережливое развитие потребителей
Важные цитаты из книги С. Альварес «Как создать продукт, который купят. Метод Lean Customer Development».
Публикация
Управление продуктами
Как создать успешный продукт. Фреймворк Jobs To Be Done
Концепция Jobs To Be Done помогает определиться с видением продукта и отдельными его функциями, которые будут привлекательны для пользователей.

С 2004 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!