Scrum: Кто создает элементы продукт-бэклога или пользовательские истории?

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

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

Кто отвечает за поддержание продукт-бэклога?

Тот, кто владелец продукта (PO)«владеет» продукт-бэклог от имени заинтересованных сторон и в первую очередь отвечает за его создание. Владелец продукта не обязан создавать бэклог лично—он или она может делегировать разработке команды и/или мастер Scrumдля помощи в определении и оценке элементов бэклога. Владелец продукта отвечает за создание и поддержание продукт-бэклога. Следовательно, владелец продукта также контролирует процесс уточнения бэклогапроцесса.

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

Является ли элемент продукт-бэклога тем же самым, что и пользовательская история?

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

Детальный продукт-бэклог

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

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

Адаптивный приоритизированный бэклог продукта

Кто отвечает за уточнение PBIs?

Ответственным за создание и поддержание бэклога продукта является Product Owner (PO), который «владеет» бэклогом продукта от имени заинтересованных сторон. PO не обязан лично создавать каждый элемент бэклога — он может привлечь команду разработки и/или Scrum-мастера для помощи в определении и оценке элементов. PO контролирует весь процесс уточнения бэклога.

Следовательно, чтобы ответить на вопрос: Product Owner владеет бэклогом продукта, но не обязан создавать каждый элемент бэклога. Обычно Product Owner может создавать крупные PBIs на основе высокого уровня требований или целей пользователей, а затем делегировать команде помощь в разбиении этих крупных элементов на пользовательские истории. Эти более мелкие истории — подходящие для верхней части бэклога и соответствующие критериям «Готово» (обычно в рамках Определения готовности) — затем перемещаются в бэклог спринта.