Há um tempo um grupo de desenvolvedores defende a ideia de que estimativas fazem mais mal do que bem – existem outras formas além de chutar um valor e uma delas é simplesmente não se preocupar com isso.

XKCD — Tasks: Nos anos 60, Marvin Minsky colocou alguns universitários, durante as férias, pra criar um programa que identificasse objetos numa foto. Meio século depois, continuamos trabalhando nisso.

Alguns podem defender que o tempo é uma informação essencial pra tomar decisões. Mas será que ela é mesmo?

Durante uma planning, temos basicamente duas variáveis pra “trabalhar”: tempo e escopo. As duas semanas do Scrum são uma sugestão, que está lá pra que você não pense em “quando vai entregar”, mas “o que vai entregar”. Se você não pode mudar “quando”, mude “quanto” (vai entregar)  –  o que é diferente de entregar uma história em quatro etapas/partes: um relatório pode ser um e-mail, uma feature, um alerta e um bug algo a menos na aplicação.

[Fazer] Design é organizar elementos pra cumprir um propósito particular.  Charles Eames

Pedir uma estimativa, mesmo sem cobrá-la depois, é transferir a responsabilidade de priorização do negócio a um time cuja especialidade é outra. Apesar de também escolher o “quanto vai entregar”, o objetivo acaba se tornando “quando” às custas de débito técnico. Pense da seguinte forma: no cabelereiro, você se preocupa em sair num horário determinado ou quando ele termina?

O Cycle Time, por exemplo, permite criar estimativas sem importunar ninguém, nem prever o futuro, mas o conforto de ter uma estimativa ainda impede o time de descobrir valores.

A metodologia ágil não é uma ciência exata e por isso ela é difícil, demorada. Manter o time ocupado é diferente de entregar valor, então elimine práticas inúteis. Que tal estimar isso?