В рамках курса «Agile Project Manager» делимся с вами переводом полезного материала.

Также приглашаем на бесплатный демо-урок «Фасилитация онлайн».

На занятии участники вместе с экспертом рассмотрят следующие вопросы:
- Обучение в онлайне – как сделать это действительно эффективно?
- Принятие решений Agile-командой – как меняется подход?
- Гигиенические правила онлайна – проверь себя сам
- Tips & Tricks при работе в онлайне – что помогает делать полезные встречи (и почему так)

Большинство Scrum команд, с которыми я встречался, не занимаются уточнением своего продуктового бэклога и пытаются делать задачи, которые они понимают не до конца. Если вы добрались до планирования нового спринта, а ваш бэклог не готов, то вы работаете с ним неправильно. Когда тот продукт, который вы делаете, не получается качественным, вам следует почитать о такой вещи, как Defenition of Done.

TL;DR

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

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

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

Что такое готовность продуктового бэклога?

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

«Выбор объема работ, которые должны быть завершены в течение спринта, может быть непростым. Однако, чем больше разработчики знают о своей производительности на основе прошлого опыта, и своем Definition of Done, тем увереннее они смогут спрогнозировать свою нагрузку на спринт.» 

- ScrumGuides.org

Если нам не нужно определение готовности, то нужно рабочее соглашение между Product Owner-ом и разработчиками. В Scrum разработчики – это те, кто выбирает какие задачи взять на спринт, и они единственные, кто может решить, что они в состоянии сделать. Разработчики должны быть уполномочены отказываться брать задачи из бэклога, которые они либо не понимают, либо их размер слишком велик, чтобы завершить задачу за один спринт. В целом, я считаю, что команда набирает на спринт достаточно большое количество задач, поэтому эти задачи должны быть подходящего размера.

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

Как детализировать бэклог? 

Уточнение не является отдельным событием в руководстве по Scrum, поскольку от продукта к продукту процесс этот может различаться. Если бы вы спросили, до какого момента нужно детализировать задачи, я бы ответил вам «столько, сколько вам нужно и больше». Слишком точная постановка задачи – это такая же трата времени, как и работа с недетализированными задачами.

«Детализация бэклога продукта – это процесс декомпозиции и дальнейшего уточнения элементов бэклога. Это постоянная работа по добавлению деталей, таких как описание, порядок работы и размер задач. Атрибуты могут варьироваться в зависимости от области деятельности»

- Руководство по Scrum 2020 года

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

Обычно я провожу первую детализацию, как воркшоп с дискуссиями. Если вы проведете его перед планированием одного спринта, то увидите его ценность к концу следующего. Для проведения воркшопа я приглашаю необходимых экспертов и Scrum-команду (Product Owner-а, разработчиков и Scrum-мастера) в аудиторию, и мы просто открываем текущий бэклог и проходимся по нему. Начните с самого верха и спросите Product Owner-а, действительно ли эта задача является самой важной. Если нет, то найдите самую важную. Затем попросите Product Owner-а прочитать и пояснить ее, а затем обсуждайте задачу все вместе, чтобы детализировать ее.

Как только Product Owner отклоняется от имеющегося описания задачи в бэклоге, остановитесь и попросите кого-нибудь занести дополнительное описание в бэклог. Попросите разработчиков оценить задачу: «Поместится ли эта задача в спринт в таком виде?». Если ответ отрицательный, то задачу нужно разбить, переупорядочить бэклог и продолжить детализировать. Вы будете делать это снова и снова, пока разработчики не согласятся с тем, что задач достаточно для следующих двух спринтов. 

Так вы поможете Product Owner-у планировать будущие релизы, а разработчикам создать план работы над текущим.

Как контролировать эффективность детализации?

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

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

Узнать подробнее о курсе «Agile Project Manager».

Смотреть открытый урок «Фасилитация онлайн».