Как определять размер задач в Product Backlog

Управление бэклогом продукта (Product Backlog) требует правильного определения объема и сложности его элементов. Слишком крупные - усложняют планирование и негативно влияют на предсказуемость завершения работы, а слишком мелкие -  создают избыточную детализацию.

(абстрактная единица оценки, с помощью которой Agile-команды оценивают относительную трудоёмкость задачи)

Основные составляющие story point:

• Объём работы: Сколько нужно сделать? Насколько велика задача по содержанию?

Пример: 10 экранов сверстать vs. 1 экран.

• Сложность:Насколько технически/логически сложна задача? Есть ли нестандартные подходы, интеграции, неопределённости?

Пример: простая форма vs. интеграция с внешним API с нестабильной документацией.

• Риски и неопределённость: Есть ли неизвестные факторы? Возможно ли появление «сюрпризов» в процессе?

Пример: задача на новом для команды фреймворке.

• Уровень знаний и опыта команды: Насколько команда знакома с задачей?

Пример: знакомый шаблон отчёта vs. новый модуль, который никто не трогал.

• Зависимости от других задач или команд:Нужно ли ждать чего-то извне? Есть ли внешние блокировки?

Для оценки в Story points обычно используют шкалу Фибоначчи: 1, 2, 3, 5, 8, 13, 21(20).

Почему рекомендуют использовать именно шкалу Фибоначчи:

При этом не рекомендуется брать в спринт больше одной задачи в 8/13/20 story points (в зависимости от веса одного story point-a в вашей команде). А в идеале декомпозировать на элементы размеров 1-5 story points.

Оценки в часах или днях понятны и привычны многим командам, особенно в проектах с жёсткими сроками и фиксированным объёмом.

Такой подход может быть уместен, когда:

• работа хорошо изучена,
• объём предсказуем,
• задачи маленькие (например, багфиксы, мелкие правки).
• если нужен “идеальный” sprint burndown chart в jira.

Однако у метода есть ряд ограничений:

• Высокий риск ошибки - в реальности часто возникают непредвиденные сложности, которые сложно учесть при попытке «точно» прикинуть время.
• Не учитывает когнитивную нагрузку - две задачи с одинаковым количеством часов могут требовать совершенно разного уровня концентрации и усилий.
• Может создавать иллюзию точности - кажется, что если мы указали «6 часов», то так и будет, и создаётся потенциально ложное ожидание, что задача будет готова в течение дня.

Метод, в котором задачи получают не числовую оценку, а «размер одежды» - от XS до XL (иногда даже XXL).
Используется, когда нужна быстрая грубая оценка, без погружения в детали.

Особенно полезен на уровне портфеля и roadmap-планирования,
например - при оценке инициатив на квартал или при формировании Backlog'а для PI Planning в SAFe.

Плюсы:

• Быстро и интуитивно
• Упрощает обсуждение приоритизации без углубления в детали
• Подходит для высокоуровневой оценки инициатив, эпиков и фичей

Минусы:

• Нет точной связи с временем или усилиями
• Требуется единое понимание между участниками: что означает «размер футболки»
• Для перехода к спринт-планированию, как правило, потребуется декомпозиция

Подход, в котором команда вообще отказывается от предварительных оценок. Вместо этого фокус - на постоянном потоке и равномерной загрузке, часто используется в Kanban или flow-based системах.

Плюсы:

• Нет потерь времени на споры и планирование оценок
• Отлично работает в потоковых процессах с мелкими, равномерными задачами
• Снижает стресс вокруг «угадали/не угадали»

Минусы:

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

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

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

Важно выбирать способ, который даёт достаточную точность (accurate) для принятия решений, но не требует избыточной детализации (precise). Цель оценки - не идеальные цифры, а общее понимание объёма, рисков и приоритетов, чтобы команда могла двигаться вперёд осознанно и уверенно.