За что отвечает Scrum команда?

Была Ретроспектива на спринт 1.0.6.
Говорили про "Прозрачность".

Проблема - Команда определяет Scope Спринта. Далее пишет фичи как может и на Демо мы все узнаем что успели. Burndwon chart показывает что дела плохи. Но команда ему не верит так как несколько задач в прогрессе, и после их закрытия все будет хорошо. Обычно куча задач закрывается за день-два до Демо. Или не закрываются. 

1) Более мелкие Stories не хотим - утраивают

2) WIP уже ограничивали - устраивает

3) Не суть

При закрытии задачи я генерирую различные замечания/улучшения которые становятся видны лишь после реализации. Команда уверена что это увеличивает Scope фич и роняет спринт. 

На Демо решили улучшить Burndown chart чтобы он работал у нас. Все согласились. Думаю и правда будет лучше - проверим.

Под конец заговорили о том почему chart не работает сейчас и вскрыли расхождение в мнениях. Пусть будут варианты А и Б.

Вариант А.

Команда на планировании сама оценивает все задачи и определяет Scope на Спринт. Если все пойдет хорошо, то именно этот объем будет выполнен через 2 недели. Команда коммитится (ну, предсказывает) что сделает все что в их силах чтобы так случилось.



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

1) Сейчас команда решает проблемы через критерий "Время" - мы обеспечивает нужное качество кода и тот Scope что хочет РО за счет времени. В результате коммитмент на Scope Спринта редко когда сбывается.
2) Балансировать за счет качества кода мы не готовы - это дорого.
3) В результате я предлагаю команде балансировать за счет Scope. 

У команды есть возможность отклонять тем замечания/улучшения что я генерирую (кроме того что в АС явно указаны). Команда отвечает за Scope Спринта - она решает что успеет сделать и что нет.

Более точный Burndwon chart должен позволить принимать решения "Успеваем/Как сильно не успеваем" не экспертно, а более формально. 

Вариант В.

Все так НО. Команда отвечает только за качество кода и продукта. Обрезать Scope во время Спринта должен РО. То есть он или не делает замечаний/улучшений или пусть не рассчитывает на успех Спринта.

Далее моя риторика.

Почему Я должен принимать решения по Scope каждой задачи? Кто принимает решения - тот и несет ответственность.
1) Команда закомитилась на некоторый Scope - я отвечаю чтобы команда его реализовала. Не хочу.
2) Этих решений слишком много - они мелкие. Не хочу.

Самое простое, наверное - это спросить у РО что ему важнее. Красиво или функционально.
Я говорю что функционально. Первый релиз, снижаем риски, нужен MMF на балансировку консолидированной модели и сценарный анализ.

А вы что думаете?