Pbr agile что это

Мультикомандное уточнение Бэклога Продукта

Командам, которые совместно работают над одним продуктом, может быть полезно проводить мультикомандное PBR. Но как можно провести PBR для нескольких команд одновременно и зачем это делать?

Перевод оригинальной статьи Сезарио Рамоса «Multi-team Backlog Refinement»

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

Что такое Уточнение Бэклога Продукта?

Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта (Product Backlog Items, PBI), которые предстоит взять в работу в следующих Спринтах. В однокомандном Скраме команда обычно проводит одну или несколько подобных встреч за Спринт.

Ниже приведены примеры связанных с этим событием активностей:

Понимание того, какую проблему надо решить: Владелец Продукта рассказывает несколько последовательных историй и связывает их с текущими бизнес-целями. Команда обсуждает “почему мы это делаем?”, “как понять, что мы решаем нужную проблему?”. Некоторые команды используют карту историй (story mapping), карту влияния (impact mapping), игры «Speedboat», «Я и моя тень» и технику «5 почему».
Разбивка больших элементов для более простого обсуждения и изучения.
Оценка элементов.
Понимание потребностей клиента: команда обсуждает“Почему пользователь хочет этого?”, “Правильно ли мы решаем его проблему?”. Некоторые команды используют доску историй (storyboard) до и после, карты Pain Gain.
Прояснение элементов: Некоторые команды используют технику спецификации на примерах (Specification By Example) и создают приемочные тесты для пользовательских историй, используют описание историй с помощью спецификаций языка Gherkin, таблицы потоков и/или таблицы решений.
Определение планов исследовательского тестирования:Выявление рисков при достижении цели, выявление фич, которые требуют ручного тестирования. Некоторые команды используют план исследовательского тестирования (Exploratory Test Charter) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…

(больше примеров можно найти в нашей статье в журнале Testing Experience)

Для чего нужно мультикомандное PBR?

Мультикомандное PBR — это мероприятие, в ходе которого все члены команд совместно уточняют PBI(s), не принимая решений о том, какая команда будет выполнять тот или иной элемент.

Ниже приведены несколько преимуществ мультикомандного PBR: (на самом деле, преимуществ гораздо больше, но их перечисление может сделать эту статью слишком длинной)

Адаптивность на уровне продукта. Почему? Потому что каждая команда понимает все PBI в Бэклоге Продукта, а не только «свои» (то есть определенное подмножество Элементов Бэклога Продукта). Если все команды понимают все PBI, тогда Владелец Продукта может разместить PBI, которые считает наиболее значимыми, выше, при этом не создавая конфликтов с теми, которые понимает лишь одна команда.
Улучшение самокоординации. Почему? Потому что команды обладают широким пониманием продукта в целом и предстоящих PBI, а значит, лучше понимают «зависимости» между PBI.
Прозрачные метрики прогресса на уровне Продукта. Почему? Потому что все команды участвуют в оценке всех PBI. Следовательно, у них одно общее понимание оценок.

Как проводить мультикомандное PBR?

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

Я предпочитаю создавать новые группы на основе участвующих в сессии PBR, вместо того чтобы использовать постоянные команды. Например, предположим, что у нас есть четыре команды: A, B, C и D. Во время Уточнения Бэклога Продукта я прошу их перегруппироваться так, чтобы все команды включали в себя по одному человеку из каждой другой команды. Для чего? С группами, включающими в себя участников других команд, все PBI уточняются по крайней мере одним представителем каждой команды. Это позволяет достичь совместного владения и широкого понимания PBI.

Форматы мультикомандного PBR

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

Я работаю со следующими четырьмя форматами:

Каждая группа выбирает один PBI и начинает его Уточнение на своей станции. После таймбокса (мне нравятся таймбоксы по 15 минут) все группы переходят на следующую станцию и продолжают PBR с того этапа, на котором остановилась другая группа. Это продолжается до тех пор пока все PBI не будут уточнены или таймбокс совещания не истечет. Группы при этом могут использовать любые подходы, которые им нравятся.

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

Частичная рулетка (Partial Roulette)

Проводится так же, как и полная рулетка, но вместо перемещения всей группы на другую станцию, один её участник остаётся. Он объясняет новой группе, что именно они обсуждали, перед тем как продолжить PBR.

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

При использовании этого подхода группы совершают расхождение-слияние после каждого таймбокса. На каждой станции остаётся по одному участнику, они становятся учителями. Затем все группы отправляют по одному участнику на каждую из других станций. Например, предположим, у нас есть группы A, B, C и D. Один участник из группы A остается на станции для обучения, один участник переходит в группу B, один — в группу C, и ещё один — в группу D. После обучения эти участники возвращаются в исходную группу и делятся своими знаниями. Любые затруднения и вопросы обсуждаются в группе.

Я применял эту методику к группам примерно до 35 человек.

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

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

Роль Владельца Продукта и клиентов

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

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

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

Цезарио занимается широкомасштабными Аджайл-трансформациями по всему миру. Автор книг «Emergent» и «Scrum Patterns». Он также является сертифицированным тренером LeSS, профессиональным тренером по Скраму (Professional Scrum Trainer™) и сертифицированным коучем.

Эффективный PBR

PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт.

В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.

Почему PBR важен

PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.

Разработчики общаются с клиентами напрямую

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

промежуточные артефакты (BRD, спецификации и т.д.);
многочисленные передачи, как результат, искажение и потеря информации;
низкая скорость принятия решений;
отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
непонимание разработчиками бизнес-домена.

Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки.

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

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

Команда в полном составе присутствует на PBR

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

Анализом занимается вся команда, не бизнес-аналитики

Еще один анти-паттерн, который я часто наблюдаю — выделенные бизнес-аналитики, занимающиеся только бизнес анализом. Они служат прокси между стейкхолдерами и командой. Часто в такой структуре в Спринте N-1 проводится бизнес-анализ, а в Спринте N непосредственно сама разработка (код, тестирование и т.д.).

Бизнес-анализ является одной из функций в команде и за нее отвечают все, а не выделенный бизнес-аналитик. Более того, возвращаясь к оригинальной концепции Скрама, Команда Разработки выполняет все активности, начиная от интервью с пользователями до поставки на рынок ценности и поддержки продукта. Работы максимально распараллеливаются. Для этого команда самоорганизуется и использует различные техники. Например, парное программирование, Swarming, моб-программирование.

Пример эффективного PBR

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

Цель, желаемые результаты, рабочие договоренности. (5 мин)

Любая эффективная встреча начинается с определения ее цели и желаемых результатов. В нашем случае цель звучала так: “декомпозировать огромную фичу, приоритезировать полученные элементы, определить минимальный необходимый набор функциональности (MVP) для реализации”. Мы договорились о том, что встреча займет не более 2х часов и через час сделаем перерыв.

Верхнеуровневое выравнивание (10 мин)

В открытой дискуссии мы потратили не более 10 мин на обсуждение фичи в формате: Кто, Что и Зачем.

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

Формируем смешанные группы (5 мин)

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

Первый раунд: разбиение (20 мин)

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

Второй раунд: переход на соседнюю станцию (5 мин)

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

Перерыв (10 мин)

Вовлеченно работать более 50-60 минут тяжело. Даже если участники говорят нам о том, что они не устали и готовы работать дальше, мы настаиваем на небольшом перерыве. Чай, кофе и глюкоза (конфеты, печенье) очень полезны. Тем ни менее, хороший знак, если кто-то остается на станциях и продолжает работать. Это сигнал высокой вовлеченности. Значит PBR эффективен.

Третий раунд: завершение разбиения (20 мин)

После перерыва мы дали еще 20 минут на то, чтобы завершить разбиение. Цель в том, чтобы получить небольшие элементы Бэклога Продукта, которые могут быть завершены в Спринте (“ready”). Ниже один из вариантов разбиения, который получился у одной из групп:

Четвертый раунд: представление результатов (20 мин)

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

Основные мысли

Стейкхолдеры, пользователи и разработчики общаются напрямую.
Полезно, когда на PBR присутствует Команда(ы) Разработки в полном составе.
За бизнес-анализ, как и другие функции, отвечает целиком Команда Разработки, нет выделенных бизнес-аналитиков.
В больших продуктах уточнением Бэклога Продукта занимаются разработчики, а Владелец Продукта оставляет за собой определение порядка элементов Бэклога Продукта (PBI).
PBR эффективно проводить, используя форматы малых групп, мирового кафе, циклы “схождения-расхождения”.

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

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

Когда?

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

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

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

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

Кто?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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