Uma forma prática de entender porque não se deve planejar software por tempo, mas sim por escopo:

São 2 cenários possíveis:

1) Pegamos a tarefa mais importante, estimamos quanto TEMPO ela custa: fica pronta na quarta; Enfiamos a cara e implementamos; Qndo ficar pronto, entregamos;

2) Estipulamos uma data - quarta - e estimamos o ESCOPO que cabe: Até quarta é possível fazer essa tarefa aqui (a mesma!). Enfiamos a cara. Entregamos na quarta de um jeito ou de outro.

Quando chegar a quarta, invariavelmente, o cliente vai achar alguns detalhes que ainda precisam ser ajustados. O que muda nas duas abordagens?

No caso (1) o que acotece é uma dessas duas coisas:
   a) ou o cliente já prometeu pra alguém na quarta e ficamos trabalhando até as 22:00, criando mais e mais bugs e acabamos deploiando uma cagada (Alguém já viu isso?)
   b) empurramos a release pra amanhã, e amanhã a gente acha mais alguma coisa pra mudar, e empurramos pra depois de amanhã, e etc. Não entregamos nunca, não temos feedback do cliente, acabamos priorizando mal os detalhes e perdendo tempo implementando uma besteira que não faz a menor diferença.

No caso (2), o que acontece é o oposto: como combinamos de entregar na quarta, e planejar por escopo (podemos remanejar o escopo), quando a data chegar a gente já viu que não vai dar tempo, simplificou a funcionalidade e entregou uma versão mais simples na quarta! Na quinta a gente prioriza o que faltou com o cliente e isso entra como melhoria na quarta seguinte, se for importante. Se não for, economizamos o esforço de implementar qq besteira e o software já está sendo usado, dando retorno ao cliente.