Идеальный Бэклог Продукта

Со временем это кладбище разрастается.

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

Это кладбище порождает нездоровое поведение внутри Scrum-команды.

Это проявляется в поведении по-разному: у команды есть противоречивые представления о том, что они делают и почему они это делают, а владелец продукта тратит свое время на создание версии Power Point невыполненной работы по продукту, чтобы сообщить команде о ее текущем статусе.

.

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

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

Двадцать — волшебное число, потому что оно способствует хорошему распорядку дня.

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

Мы эмоционально привязываемся к пользовательским историям, когда тратим время на работу над ними, и нам становится трудно отпустить их.

Для этого даже есть специальный термин «ФОТО», что означает страх выбросить.

Если вы сможете преодолеть этот страх, ваше видение продукта станет более ясным, а ваша команда сможет сосредоточиться на будущем.

И просто помните, что выбрасывать что-то на самом деле очень приятно.

Добавьте свою дорожную карту и видение в список невыполненных работ по продукту.

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

Объедините все ваши планы развития продукта и бэклог в один список.

Закон Конвея заставляет нас думать, что использование различных инструментов для управления работой и стратегией, таких как JIRA для бэклога (да!) и дорожных карт, — плохая идея.

Такой подход превращает девелоперские предприятия и организации в сараи.

Так что разрушьте эту разрозненность, повысьте прозрачность и дайте своей команде контекст, необходимый для создания отличных продуктов.

Для этого поместите один единственный бэклог на видном месте и убедитесь, что в нем не более 20 пользовательских историй.

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

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

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