И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
Где умирают пользовательские истории
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
Как воскресить бэклог продукта, чтобы он стал идеальным?
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
- Начните с сокращения бэклога, если в нем уже более 20 пользовательских историй. Двадцать – это волшебное число, потому что оно способствует правильному режиму. Вы когда-нибудь смотрели ту серию Hoarders, где человек, по жизни очень успешный, не мог расстаться с тысячей банок из-под попкорна, которые он собирал десятилетиями? То же самое происходит и с бэклогом продукта по мере его роста. Мы эмоционально привязываемся к пользовательским историями, когда тратим свое время на их проработку, и нам уже становится трудно отпустить их. Для этого даже есть специальный термин «FOTO», который означает страх выбрасывания. Если вы сможете преодолеть этот страх, то ваше видение продукта станет более ясным, а ваша команда сможет сосредоточиться на будущем. Да и просто помните о том, что выбрасывать что-то на самом деле очень приятно.
- Добавьте свою дорожную карту и видение в бэклог продукта. По моему опыту, команды, которые не видят ничего дальше следующего спринта, чувствуют себя потерянными, лишенными мотивации, они тратят больше времени на переживания о том, стабильна ли их работа в целом, чем на проработку новых функций.
- Объедините все дорожные карты и бэклог вашего продукта в один список. Закон Конвея наводит нас на мысль о том, что использование разных инструментов для управления работой и стратегией, таких как JIRA для бэклога (ага!) и для дорожный карт – это плохая идея. Такой подход превращает бизнесы и организации, специализирующиеся на разработке, в подобие амбаров. Так сломайте эти амбары, увеличьте прозрачность и предоставьте своей команде контекст, который ей нужен для создания отличных продуктов. Чтобы это сделать – положите один единственный бэклог на видное место, и позаботьтесь о том, чтобы в нем было не больше 20 пользовательских историй.
- Используйте время, оставленное на доработку для создание идеального бэклога продукта, а не на создание пользовательских историй для следующего спринта.
- Рассказывайте об актуальном продуктовом бэклоге при обсуждении прогресса, например, при ревью спринта, чтобы ваши клиенты и руководители чувствовали себя комфортнее, и точно знали, где его можно найти.
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.
