Всмысле докинуть и посмотреть что получится?)

а у вас же был разговор на эту тему?
прежде чем человек берет задачу в разработку он коммитится на том, что все задачи за итерацию будут сделаны?

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

Основной посыл следующий:
1. относиться к срокам/истемейтам/.. проще и сразу подразумевать факап (а-ля лет ит фейл);
2. нужно разобраться, что разработчику мешает: может ему надо из дома работать или слишком душно в помещении

Хорошо, что уже появляются компании, которые спокойнее относятся к "косякам"

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

Да, относится проще — единственный способ сберечь нервы) А что мешает... ну, опенспейс, конечно же :)

речь же о систематике. Если человек/команда систематически обещает и не делает, то есть проблема и ее понятно как решать

Могу только апплодировать этому человеку)

сорри, я может быть новичок, но мне не понятно как решать :)

поменяться местами. Пусть они сами запланируют такой объем задач и выполнят его хорошо и вовремя

ну вводите коэффициент производительности команды, XP, ...
Техники есть, вопрос насколько точно они будут работать

накой вводить коэффициент если у вас есть ситематическая ошибка? может лучше бороться с проблемой а не заниматься pi-менеджментом?

Что именно является проблемой?
У меня 2 варианта:
1. Команда из раза в раз оценивает, факапит, ... (естественно разрабы переживают, производительность ещё больше падает, ..)
2. Конкретно для этой команды эстимейты вообще не работают

пока платят за отсиженное время, а не результаты... нет, не мотивирует

Первое: оценили-запланировали-не сделали (повторить 1000раз)

Хорошо, всё понятно) Тогда остаётся только пожелать удачи и дальше пытаться чинить то, что надо давно выкинуть

В одной из команд я проводил эксперимент: уменьшал скоуп все сильнее и сильнее. (У этой команды за 2 года не было выполнено ни одного срока) и вы не поверите, какой скоуп не был они все равно его факапили

Как разработчик, работающий заместителем тимлида, поддержу Татьяну. Используем скрам, оценки задачам даём с помощью модифицированного planning poker, в конце спринта вся команда видит таблицу, сколько задач и часов работы было запланировано, сколько сделано у каждого. Обсуждаем технические сложности, почему задержались задачи или не сделались. На оцениваниях работы и решениях об изменении зарплаты менеджер учитывает эти показатели по крайней мере раз в полгода. Слишком «свободных художников» видно и до всяких бесед о зарплате, после двух-трёх спринтов. Если у них есть уважительные причины (болезни, другие, сессии в университете, отсутствие опыта), то об этом знает менеджер и даёт тимлидам наводки, чтобы делали скидку. Если нет причин, то постепенно на этих людей идёт меньше важных задач, командировок, презентаций начальству, меньше ответственности, потом это и на зарплате сказывается,  а дальше вплоть до переводов в другие отделы и увольнений.

К слову, за последние пол года эта же команда не продолбала ни одного срока