Успеть к релизу: практический гайд по сравнительной оценке бэклога

Метод сравнительной оценки, который мы рассмотрим ниже, помогает быстро оценить команде сложность объема работ бэклога релиза или MVP, обнаружить в самом начале работы все сложные и непонятные задачи, которые могли бы стать потенциальными проблемами и заранее составить план работы с ними. Если у вас есть необходимость проверить, действительно ли ваш релиз будет завершен через несколько месяцев и какие слепые зоны в вашем продукте для команды сейчас есть (и которые впоследствии могут сыграть против вас) — используйте подход сравнительной оценки, описанный ниже.

Шаг 1. Определите правила совместной работы

В начале встречи установите простые, но эффективные правила взаимодействия:

• Работаем единой группой, чтобы мнения не размывались и решение принималось коллективно: вся команда находится вместе, без разделения на комнаты.
• Уважаем чужие взгляды и идеи, даже если они отличаются от ваших.
• Если в ходе обсуждения появляются вопросы, на которые нет ответов, «паркуем» их — фиксируем для отдельного обсуждения, чтобы не отвлекаться.
• Смотрим реальную картину, не стараемся подогнать итог под желаемый результат.

Шаг 2. Проведите верхнеуровневый Product Backlog Refinement

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

По порядку одну за другой обсуждаем карточки с командой по следующему алгоритму:

• Убедитесь, что в бэклоге максимум 25–30 карточек — так команда сможет сфокусироваться на главном.
  
• Не углубляйтесь в детали и обсуждайте каждую карточку ровно настолько, чтобы понять её относительную сложность и сопоставить с соседними задачами.
• Исключите из оценки задачи, которые уже находятся в работе или запланированы в текущем спринте.
• Перенесите в отдельный список задачи, которые возможно будут реализовываться в следующем релизе, чтобы не мешать текущему воркшопу.

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

Шаг 3. Сравнительная оценка задач

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

Как это сделать:

1. Команда выбирает из бэклога одну задачу, которую считает понятной и средней по сложности. Эту задачу обозначаем как эталон — она попадёт в категорию «M» (medium, средняя).
   
2. Берем по очереди другие задачи и сравниваем их с эталонной:
   
   • Если задача кажется примерно такой же по сложности, ее тоже относят к категории M.
     
   • Если задача примерно в 2 раза легче, относим ее к категории «S» (small, маленькая).
     
   • Если задача примерно в 2 раза сложнее — к категории «L» (large, большая).
     
3. Таким образом, мы разбиваем весь бэклог на категории сложности: XS, S, M, L, XL. Очень большие задачи, а также задачи с высокой неопределенностью для команды, помечаются размером XXL. Их не нужно долго обсуждать — если, например, вы видите, что у команды сейчас нет архитектурного решения и начинается спор, смело предлагайте завершать обсуждения и отнести эту карточку к самому большому размеру.

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

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

Шаг 4. Привязка оценки к времени и подсчет общего объема работ 

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

• Команда оценивает, сколько примерно времени (в днях или спринтах) требуется на выполнение одной задачи средней категории M. Например, если команда считает, что средняя задача занимает 0.5 недели — это отправная точка.
  
• Используем степень двойки и для задач категории S время считаем как в 2 раза меньше, для L — в 2 раза больше, для XL — еще в 2 раза больше и так далее.
• Далее умножаем оценку времени на количество задач в каждой категории и суммируем результаты. Таким образом, мы получим очень приблизительную оценку, которая тем не менее позволит понять, какой срок нам понадобится на заданный объем работ.
• Важно: задачи с категорией XXL обычно содержат значительную неопределенность, поэтому в дни их не переводят и в расчетах не учитывают, а в итоговом результате фиксируют только количество найденных XXL. О работе с ними мы поговорим в следующем шаге.
  

Шаг 5. Работа с задачами с высоким риском и неопределенностью

Задачи, которые вызвали сомнения или отнесены к категории XXL, выносятся в отдельный список:

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

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

Шаг 6. Построение роадмапа и поспринтового плана

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

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

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