Соотношение отклонения по срокам к размеру буфера.

судя по графику - нет :) Хотя в теории должен был быть именно проект внутри продукта, со сроком, скоупом и прочим. Но в какой-то момент что-то пошло не так. И не очень понятно что.

Стали накидывать идеи "Очень важная  фича". И цель изменений пртеряли.

И могу предположить что общее состояние людей "пилим продукт".

Были бы цели шло бы ступеньками.

В начале там были ступеньки :) И задач вроде не особо накидывают. Учитывая что это уже не первая попытка запустить проект, вышедшая из под-контроля, кажется что их надо делать просто меньше, чтобы не успевали расфокусироваться на мелочи.

Насколько корректны такие мои выводы?

Выводы верные. Важно выбрать правильную длительность проектов. 8-12 недель как правило хватает для рывка.
Но тут важен Фокус на Цели.

https://pulsemanagement.org/rules-deceisions-by-buffer/

тут расчет показателей:

https://pulsemanagement.org/rules-scope-buffer/

Скоуп менеджмент отбросили как тормозящий достижение результата

А зачем вам проект? Для чего?
Поддержка проекта стоит ресурсов в виде времени людей. Зачем это время тратить?

Это ты так троллишь? %)

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

Конечно фичи можнот тоже как проекты делать, но они таааакие коороткие, что толком анализ успешности не проведешь.

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

А задачки от бизнеса регулярно прилетают, да?

Насколько я вижу - нет или почти нет. Выглядит так, что каждая сделанная задачка по факту выполнения генерирует еще три задачки на доработку/фиксы. На досуге попробую разделить эту историю на типы работ и посмотреть что там глубже живет

Из моей практики, это достаточно частое  поведение в ситуациях:
1  "некогда думать. делать надо"
2  "давай сначала сделаем, а потом посмотрим как оно работает"   (привет Скраму с эмпирическим подходом)
3  "разработчику надо очень попасть в оценку"

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

Задачи в начале декомпозируются менеджером, а дальше уже и разработка вполне может заводить задачки. В текущий момент времени задачек разработкой заведено столько же, сколько и менеджером. Скоро от разработки станет больше задачек. Делались они исторически в соотношении 1-к-3, что весьма интересно, поскольку эта цифра идет достаточно стабильно.

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

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

Интересная ситуация!

Но график показывает, что никакой декомпозиции нет. иначе были бы ступеньки %(
Даже при набегающей волне, должны быть ступеньки каждую неделю, так  как декомпозиция выглядит моментальным ростом на графике возгорания.

Для фокусировки рекомендую сессию запуска проводить по этому формату:  https://pulsemanagement.org/rules-project-charter/
Если жестко ставить под сомнение формулировки, можно реально сократить объем работ и уточнить цель.

Чтобы советовать надо узнать контекст. Иначе совет будет абсолютно правильным и таким же бесполезным.
К примеру, "вам нужно управление объемом работ".
Пользы от такого совета не много. Только если похоливарить ;)

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

Сработало Scrum + надстройки. Они переходили между SAFe, Less, Nexus.

> Насколько я вижу - нет или почти нет.
> Выглядит так, что каждая сделанная задачка по факту выполнения генерирует еще три задачки на доработку/фиксы.

Звучит как самообман.
Откуда может появиться задача на доработку, как не от бизнеса?

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

1. Напиши плиз разбивку по задачам на доработку - кто источник задачи? входила ли задача в изначальный объем задачи, или это расширение?
2. Такую же разбивку по фиксам. Часто бизнес доработки тоже тащит как фиксы.
3. Каков процесс работы команд - есть ли product owner? кто выставляет приоритеты задачам? кто приоретизирует задачи пришедшие от разных заказчиков?