Структурирование бэклога по размеру
Структурирование бэклога по размеру — это целенаправленная группировка элементов (bаcklog items) по их относительной трудоёмкости или масштабу и последующее управление каждым «слоем» с учётом его природы.
Зачем нужен
Позволяет представить не только тактическое “как” проекта, но и стратегическое “что” без преждевременных цифр. Создаёт предсказуемый поток для дальнейшего мониторинга и прогнозирования. А также позволяет снизить риск “scope creep”, поскольку любое расширение характеризуется дополнением нижнего уровня.
Когда применять
Эта практика применяется при достаточно длительном времени, начиная с того момента, когда features (и иные верхнеуровневые элементы) разбиваются на составляющие пользовательские истории (user story) в ходе работ по доработке журнала невыполненных работ.
Когда не работает
Структурирование бэклога по размеру может быть неэффективным в нескольких случаях: во-первых, когда размер бэклога слишком велик, что затрудняет планирование и оценку; во-вторых, когда команда не имеет достаточного опыта в решении задач; в-третьих, когда бэклог содержит очень разные по сложности элементы, которые невозможно легко масштабировать.
Как применять
Пример PMI disciplined-agile
Следует начать с гейта Intake Work: каждый новый запрос оценивается, и если он превышает допустимый предел (в Disciplined Agile для рабочей user story это ≤ 3 дней усилий), его тут‑же декомпозируют на несколько меньших элементов — сначала до Feature, затем до User Stories, сохраняя трассировку «ценность → функция → задача».
Поддерживайте в бэклоге чёткие слои: Value Increments задают стратегический вектор портфеля, Features формируют дорожную карту релизов, а User Stories заполняют ближайшие спринты; элементы опускаются на уровень ниже только после прохождения Definition of Ready соответствующего слоя.
Раз в 1‑2 недели проводите сессию Refinement, где команда вместе с владельцем продукта дробит верхние Feature до stories «весом» 1‑3 дня, удаляет устаревшие идеи и объединяет дубликаты. Для каждого слоя задайте лимит WIP (например, ≤ 50 Feature, ≤ 100 Story); его превышение служит сигналом, что пора приоритизировать или отказать запросам, а не расширять очередь.
Наконец, калибруйте «правильный» размер stories по фактическому throughput — если задачи регулярно «перетекают» между спринтами, дробите их; если закрываются слишком быстро, агрегируйте в более крупные функции. Такой цикл «приём → декомпозиция → исполнение → обратная связь» поддерживает одновременно стратегическую гибкость и оперативную предсказуемость проекта.
Дополнительно пример схемы декомпозиции от SAFe см картинку