Pbr agile что это

Настройка активности Product Backlog Refinement (PBR)

PBR он же в старой версии Scrum Guide “grooming” — очень важная и эффективная активность, которой могут пренебрегать команды. Данная активность помогать более эффективно подготавливать элементы бэклога продукта для взятия их в работу в итерации (спринты).

С чем приходить на PBR?

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

Зачем брать с собой элементы бэклога текущего спринта? Это позволяет команде оценить риски выполнения в течение текущего спринта. Если есть понимание, что что-то будет не выполнено, это учитывается при планировании объёма на следующий спринт.

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

Что же может происходить на PBR?

1. Добавление новых элементов бэклога продукта. Обычно это делает владелец продукта (ВП). При добавлении нового элемента, ВП может уточнить сложность элемента для понимания примерно сколько он будет реализовываться. Для этого команда использует Planning Poker или Scrum Poker. Это необходимо для размещения данного элемента внутри бэклога продукта. Если команда может сделать этот элемент быстро, то ВП может принять решение о размещении данного элемента бэклога сверху, если команда говорит, что элемент сложный и нужны уточнения, то элемент может переместиться ниже более понятных и актуальных элементов.
2. Переприоритизация элементов бэклога продукта(что-то стало срочным, что-то могло потерять актуальность).
3. Декомпозиция элементов бэклога продукта. Большие элементы бэклога, которые не могут быть реализованы за одну итерацию, декомпозируются на меньшие по размеру элементы, которые занимают свою очерёдность в бэклоге продукта. Как декомпозировать можно посмотреть здесь
4. Добавление деталей к элементам бэклога продукта. К деталям также относятся критерии приёмки/успешности — “Как мы поймём, что мы сделали то, что от нас просили”.

Дополнительно к элементам бэклога со стороны команды к ВП могут быть предложены дополнительные требования — критерии готовности: какую информацию должен содержать в себе элемент бэклога продукта. Это позволит ВП подготовиться заранее к PBR.

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

P.S. В следующей статье я расскажу о том когда лучше проводить PBR 🙂

Уточнение Бэклога Продукта [Груминг Бэклога] (Product Backlog Refinement)

Уточнение Бэклога Продукта — это активность, которая проводится Владельцем Продукта при участии всех членов Скрам-команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).

В русском жаргоне адептов Скрама для этой практики прижилось название Груминг Бэклога (а также такие переводы слова Grooming как Уход за бэклогом и Причесывание бэклога). Это связано с тем, что в Scrum Guide до 2013 года использовался термин Grooming, а не Refinement.

В Скраме рекомендуется от 5 до 10 процентов времени каждого Спринта выделять на Уточнение Бэклога Продукта. Этот процесс включает:

• Анализ уточненных требований
• Декомпозицию: разделение крупных элементов на более мелкие (от Эпиков к Пользовательским Историям)
• Оценку новых элементов
• Переоценку существующих элементов

Уточнение Бэклога Продукта проводится не для того, что уже взято в работу в текущем спринте, а для будущих спринтов. Хорошей практикой считается иметь в Бэклоге Продукта детально проработанные элементы как минимум на два Спринта вперёд. В этом случае Планирование Спринта существенно упрощается, поскольку Владелец Продукта и Скрам-Команда начинают планирование с понятным, прошедшим этап анализа и аккуратно оцененным набором пользовательских историй. Если же груминг Бэклога не был проведён (или был проведён недостаточно хорошо), Планирование Спринта растянется во времени, вызовет большое количество вопросов, потребует уточнений и/или выявит несоответствия.

Для пользовательских историй существует два критически важных этапа: «Готово к разработке» и «Сделано». Для них должны быть, соответственно, критерии готовности к разработке (Definition of Ready) и Критерии готовности (критерии завершения работы над историей, Definition of Done). И Уточнение Бэклога — это процесс или встреча, в ходе которого Владелец Продукта удостоверяется в том, что пользовательские истории «Готовы к разработке», то есть команда может немедленно взять их в работу и перевести их в «Сделано».

Больше по теме «События и активности»:

Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.

Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.

Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:

• Почему этот Спринт ценен?
• Что может быть сделано в этом Спринте?
• Как будет выполняться выбранная работа?

Одно из 5 Мероприятий Скрама. Ретроспектива Спринта дает Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием Спринта. Для Спринта длиной в месяц эта встреча ограничивается 3 часами.

Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

• Что мы делаем
• Наша команда
• Блог
• Контакты

• Расписание тренингов
• Карта тренингов
• Сертификации
• Обучение Scrum Master
• Обучение Product Owner
• Обучение Kanban

• Услуги для компаний
• Тренинги для групп от 10 чел.
• Кейсы клиентов

Когда проводить PBR и кому на нём следует быть

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

Когда?

Бывает, что команда выбирает PBR не как одно событие за спринт, а как серию событий, которые спонтанно возникают в календаре, т.е. из спринта в спринт их время меняется и их несколько за спринт.

Такое возможно для команд, которые достаточно зрелые и у них большая неопределённость у элементов бэклога продукта. Такое возникновение PBR в календаре “Как только возникла необходимость” требует хорошей дисциплины от команды и возможности отвлечения от текущих задач без потери фокуса.

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

Чаще команды планируют PBR дня за 2–3 до окончания спринта , чтобы было время до планирования следующего спринта, так как одна из основных задач PBR это получение ответа на вопрос “Готовы ли мы к следующему спринту?”

Кто?

Существует несколько мнений по данному вопросу. Есть мнение, что на PBR могут быть не все участники команды, есть мнение, что все участники команды.

Если мы вернёмся к ответу на вопрос “Когда?” и он будет “Как только появилась необходимость?” то, возможно, вам не нужны будут все участники, т.к. скорее всего это будет встреча по каким-то определённым элементам бэклога, которые в работе у части команды и это оговорено командой заранее.

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

Представьте, если будут вопросы по back-end, а в это время все ребята знающие BE не придут на PBR, другие могут посчитать встречу, как бесполезную потерю времени.

Пишите как у вас проходит PBR и с какими трудностями сталкиваетесь вы 🙂

Уточнение бэклога в LeSS (PBR) — виды и применение

Product Backlog Refinement в LeSS включает в себя многокомандный PBR (совместная работа всех команд над бэклогом), общий PBR (обзор бэклога всеми командами или их представителями) и однокомандный PBR (работа одной команды над сложной задачей). Эти методы способствуют обмену знаниями, улучшению координации команд и адаптивности процесса.

Уточнение бэклога продукта (Product Backlog Refinement, PBR) — это фундаментальный и непрерывный процесс, который происходит в течение каждого спринта для проработки элементов бэклога, которые будут взяты в следующие спринты. Основными видами деятельности в PBR являются декомпозиция крупных элементов и их уточнение до тех пор, пока они не будут готовы к реализации без дополнительных вопросов, а также оценка размера, трудоемкости, рисков и так далее.

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

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

В LeSS существует три типа PBR:

• Многокомандный PBR
• Общий PBR
• Однокомандный PBR

Давайте разберем каждый тип PBR в рамках масштабного Scrum (LeSS) в более подробном виде.

Многокомандный PBR (основной тип)

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

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

Уникальная стратегия, используемая в многокомандном PBR, — это «уточнение бэклога в смешанных группах”.

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

Общий PBR

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

На общем PBR присутствуют владелец продукта и либо все члены команды, либо несколько представителей от каждой команды. Цель состоит в том, чтобы встреча была эффективной, при этом обеспечивалось представительство всех команд.

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

PBR для одной команды

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

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

Важно отметить

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

Однако в любом случае, при внедрении LeSS в организации, следует стремиться к как можно более быстрому переходу к многокомандному PBR.