Как управлять бэклогом продукта с помощью принципов DEEP?

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

Владелец продукта несет ответственность за бэклог продукта, включая его содержание, доступность и порядок.

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

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

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

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

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

Роман Пихлер — автор книги Agile Product Management with Scrum. Упоминается:

«Создание продуктов, которые нравятся покупателям. Мы используем четырехбуквенную аббревиатуру DEEP для описания характеристик хорошего бэклога продукта». — это описательная аббревиатура качества продукта невыполненной работы в Scrum, которая означает:  Детализированный соответствующим образом,  Предусмотренный ,  Оцененный и  Расставленный по приоритетам.

Подробно

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

Оцененный

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

эмерджентный

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

Приоритет

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

Резюме

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

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