Uma estimativa do tempo necessário para entregar um produto é uma das informações solicitadas com mais frequência pelos clientes, e é um pedido que costuma deixar desconfortável uma equipe ágil. Embora estimar as funcionalidades de um produto inteiro, sem ter começado a trabalhar nele efetivamente, tenda a gerar muitos erros, trata-se de uma pergunta prática que as equipes não podem ignorar.
Jarrod Roberson disse que nunca se deveria estimar um projeto inteiro, pois isso iria totalmente contra a filosofia ágil. O melhor a se fazer seria atribuir uma data dependente do custo ou de outras restrições - e o Product Owner decidir o que deve ser feito até aquela data. Pascal Thivent acresenta que qualquer estimativa inicial resultaria em um escopo fixo, o que vai contra os princípios do Agile. Outro extremo sugerido foi que times ágeis nunca entrem em projetos que envolvam estimativas iniciais.
Entretanto, isso funciona no mundo real? Com frequência, times ágeis se defrontam com a situação em que o cliente precisa de uma estimativa, mesmo que grosseira, a fim de tomar decisões. Sobre isso, disse Hugo Palma no site StackOverflow:
Acredito que todo cliente quer ter pelo menos uma estimativa de quanto irá custar certo conjunto de funcionalidades. Não concordo com pessoas que afirmam que isso é impossível quando se usa práticas ágeis. O Agile pode ser adaptado ao mundo real, em que clientes querem saber quanto irão gastar em um projeto, ou pelo menos obter uma ideia aproximada.
Mike Cohn comenta que costuma receber perguntas sobre estimativas de horas para a entrega de produtos. Sua primeira recomendação, nesses casos, é adiar a análise até que se tenha informações históricas adequadas, ou pelo menos até terem sido realizadas algumas reuniões de planejamento. Entretanto, há situações que precisam de uma estimativa aproximada antes disso. Para estas situações, Cohn sugere uma técnica de trabalhar com uma amostragem do backlog, verificando uma média de horas para cada tamanho de história.
Se medirmos as histórias, podemos verificar que uma história de 1 ponto pode corresponder a 3,2 horas por ponto; as de 2 pontos (que foram quebradas em tarefas) teriam 4,3 horas por ponto; e as de 3 pontos, 4,1 horas por ponto; e assim por diante. Poderemos então multiplicar o número médio de horas pelo número de histórias do backlog do produto, para cada tamanho.
Mike adverte que esta técnica herdaria todas as deficiências introduzidas durante a identificação de tarefas e na fase de estimativas. Rob Bowley comentou que a técnica de amostra do backlog não funcionaria, já que o desenvolvimento de software é imprevisível e que técnicas como esta acabariam subestimando a quantidade de trabalho necessária.
Não há justificativa para se tentar fazer algo desse tipo. A quantidade de trabalho vai acabar sendo subestimada enormemente. E considerando a quantidade de dinheiro envolvida no desenvolvimento de software, isso acabará causando danos financeiros reais a uma organização, ou mesmo destruindo carreiras.
Matteo Vaccari comenta que, apesar da estimativa por amostragem do backlog poder ajudar com alguns números, continuará existindo várias incógnitas, como a maturidade do time, a experiência em trabalhar juntos, a definição de "pronto" utilizada etc., que tornariam a estimativa menos útil.
Outra opção nessas situações é o Escopo Flexível, sugerido por Martin Fowler. A ideia é começar com um contrato de escopo fixo e aos poucos educar o cliente sobre os méritos das práticas ágeis, ajudando-o a superar a Miragem do Escopo Fixo. Rob Thomsett também sugere um jogo de dobrar e adicionar, que é similar à técnica descrita por Fowler.
Assim, nenhuma das técnicas parece realmente completa. Cada uma sofre com algum elemento subjetivo e tem suas próprias armadilhas. De qualquer forma, as aplicações das técnicas em situações que demandem uma estimativa aproximada pode ser útil ao cliente e a outros interessados, para que tenham mais informações nas quais basear suas decisões.