так что каждая часть может (и должна) быть протестирована независимо от других.

Пожалуй стоит открыть новую тему "вред и польза от юнит тестов"

Невозможно все стричь под одну гребенку.

Вот был проект, довольно долгий. Там данные от устройства передавались по СОМ порту и декодировались. Это была одна из важных функций. Были отдельные тесты для "декодера" и была сделана система для генерации потока данных через СОМ порт, был даже человек который какое то время только и писал сценарии тестирования. Но это было необходимо, так как различных устройств было довольно много, партии устройств были довольно крупные и устройства не могли запросто выдавать неверные данные типа "30 февраля". Реализация всей системы заняла несколько недель, не считая кучи сценариев и того что через какое то время пришлось все сценарии перекраивать, так как в устройствах что то изменилось.

Теперь допустим есть другой проект, только для одного заказчика который выполняет какую то важную работу и как бы между прочим получает данные о весе через СОМ порт (которые впрочем можно ввести и вручную). Будем ли мы городить все тоже самое для этого проекта?

Ну и нужно, чтобы вся команда следовала TDD.

зачем? и почему не допустим BDD?

не может быть одного решения на все случаи жизни.

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

Каким образом из положения бумажек видно "почему"?

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