Первый артефакт, описанный в Scrum Guide – бэклог продукта.

Бэклог продукта (Product Backlog) содержит все требования к продукту, которые команда разработки должна реализовать. Владелец продукта несет полную ответственность за бэклог продукта. Scrum не предписывает конкретную форму ведения этого артефакта. Каждая запись в этом списке просто называется «предметом/пунктом бэклога продукта (Product Backlog Item)». Основная цель владельца продукта – напоминать команде разработки, что он хочет от них получить. Необходимо постоянное сотрудничество между владельцем продукта и командой разработки для разъяснения каждого элемента. Это постоянное взаимодействие сильно отличает Agile методологии от традиционного управления требованиями. Когда все требования изложены до начала проекта – экономия времени. Бэклог продукта всегда упорядочен (обычно самые ценные элементы стоят выше), прозрачен. Элементы для следующих двух спринтов достаточно описаны. Других источников работы для команды разработки нет.

Пример бэклога продукта

Пример бэклога продукта

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

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

Учетная карточка бэклога продукта

Пример учетной карточки продуктового бэклога

Помните правило:

Один продукт → Один владелец продукта → Один бэклог продукта

Содержание бэклога продукта:

  • Запросы функций: любой запрос от заинтересованного лица. Например, «Я хочу иметь возможность отсортировать этот список».
  • Эксперименты: функциональность, разрабатываемая для тестирования на рынке (например, новый пользовательский интерфейс, опрос пользователей, аналитика).
  • Пользовательские истории.
  • Ошибки/ дефекты: проблемы, возникшие в предыдущем релизе.
  • Возможности: различные способы или каналы доступа к существующим функциям (например, мобильные, веб, облачные сервисы, общедоступный API).

Критерии хорошей пользовательской истории (DEEP):

  • Достаточно подробная (Detailed) – написаны критерии приемки
  • (Emergent) – бэклог продукта никогда не бывает «полным». Он уточняется с течением времени.
  • Оцениваемая (Estimated).
  • Отсортированная по приоритетам – по стоимости, риску, стоимости, зависимостям и так далее.

Пример элемента бэклога продукта с критериями приемки