Простите, но у вас во многих сообщениях читается протест против конторы/команды в которой вы работаете

Ну допустим, а какая разница? К обсуждению это отношения не имеет.

У нас практика распространена следующая - мы считаем капасити команды по дням, потом переводим это в сп (3 дня 1 сп), оцениваем стори в сп (держа в голове, что 1 сп - 3 дня) и при этом не оценивая исторические данные по велосити вообще. Отличный пример, как не надо делать.

При этом wsjf и майки я только поддерживаю 🙄

Не имеет, но для вас может быть сигналом, не более того.

Спасибо. Я в курсе, осознанность присутствует.

А какие реальные симптомы того, что подход не работает? В спринте остаются несделанные задачи, идёт срыв сроков/обещаний стейкхолдеров и тд

Да, все в наличии (но, кончено, причины могут быть не только в эстимировании).

Деление задач приводит к потере информации. Частотная диаграмма, про которую рассказывал @controlchart https://youtu.be/F9-pBAWUvoE

Мы съедаем слона по частям, но нам важна информация не о том, как быстро мы жуем кусок (это почти всегда одно и то же), а то как быстро мы съедаем слона такого типа.

Сейчас у меня был яркий пример:
- одна команда не занималась излишней декомпозицией
- другая занималась

В итоге у первой команды ярко видно классы задач по времени обслуживания.

А во второй команде эта информация потеряна

Каков механизм потери информации в результате декомпозиции?

Вместо инфы что мы едим слона за 30 дней у нас инфа: ногу едим за 5 дней, тело за 11, голову за 4. И нет данных об эмерджентных свойствах поедания слона. Мы суммируем.... и не попадаем. Потому оценивать важно целиком

А что мешает оценивать не только части слона но и всего слона?

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

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

Если большую задачу продолжать отслеживать (на уровне feature в Microsoft Solution Framework) то норм

Получается вообще бесполезно оценивать? Или только в каких-то конкретных обстоятельствах?

Имею в виду диаграмму распределения lead time  как раз )

Смотри, дать прогноз завершения можно, и есть для этого инструменты. Бесполезно оценивать работу по критериям типа: объем работы, сложность работы, неопределенность и т.п.

а можешь прокомментировать, ты выше написал фразу "классы задач по времени обслуживания", что там имелось в виду?

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

Похоже на 5 классов задач

По оси X - lead time в днях
По оси Y - количество таких задач

На глаз в правой части графика мало данных