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

Задача "на неделю" должна быть быть разбита минимум на 5 подзадач.

Что значит "функционал появится только по окончанию сборки всех частей"? Очевидно, что функционал есть у каждой из частей. В конце концов есть юнит-тесторование, при котором наличие других частей - это скорее вред, чем польза. Так что каждая часть может (и должна) быть протестирована независимо от других. А после того, как будут сделаны все части, надо будет провести тестирование всех частей вместе - интеграционное тестирование.

Одну часть теоретически можно и протестировать, но для этого нужно будет написать эмулятор оборудования, который будет в корне отличаться временными характеристиками. Да и времени это может занять также неделю. Как же тогда считать выполнение ежедневного задания?

Мы тут уже как-то говорили про юнит-тесты. Есть интерфейсы, есть фреймворки. О тестировании надо думать до того, как приступаешь к написанию пропуктивного кода. Идеально, если тесты пишутся перед продуктивным кодом. Но это уже совсем высший пилотаж. Ну и нужно, чтобы вся команда следовала TDD.

А что конкретно под этим имеется в виду?

Каждый понимает свое. Для кого-то достаточно заполненых summary тэгов, кому-то надо еще дополнить chaneslog.txt, где-то надо зачекинить в определенном месте все е-мылы и документы по данной теме. Никаких правил тут нет :)

И подобных случаев довольно много.

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