No post Planejamento a Longo Prazo com o Uso de Histórias do Usuário, George Dinwiddie apresenta seu ponto de vista sobre como fazer estimativas utilizando métodos ágeis. Ele explica que as histórias podem ajudar as equipes a concluírem as tarefas, mas planejar uma nova versão (release) com histórias pode ser um esforço grande demais, inviável para uma equipe:
Se uma versão criada em três meses (13 semanas com 5 dias úteis, totalizando 64 dias úteis) é dividida em histórias que levam dois dias cada uma, então serão aproximadamente 32 histórias. São muitas, mas podem ser ainda mais caso sejam desenvolvidas simultaneamente, ou se algumas delas forem menores. Se metade da equipe se envolve em cada história e metade das histórias são de apenas um dia, então a contagem de histórias aumenta para 96. Imagine uma equipe no início do projeto separando dessa lista de quase 100 histórias as que cabem em três meses, ou as que já se sabe quanto tempo levará para fazer o que precisa. Parece muito trabalho, não é? (E isso para um projeto pequeno.)
George sugere o uso de funcionalidades (features) ao invés de histórias para estimar as novas versões:
Eu listaria as funcionalidades conhecidas (que algumas pessoas chamam de histórias grandes ou épicos), as ordenaria em pilhas de tamanho aproximado e estimaria os tamanhos percebidos, o melhor que puder com base em qualquer experiência histórica que tivesse.
Eu poderia testar essas percepções quando estivesse implementando a primeira funcionalidade, e ajustaria minhas expectativas de acordo com os resultados empíricos. Conforme o andamento, poderia continuar refinando as minhas expectativas; e repensar a qualquer momento quais funcionalidades são realmente necessárias ou quanto esforço colocar em uma funcionalidade - isso porque ainda não teria investido muito esforço nela.
Por que é tão difícil estimar e o que pode ser feito para facilitar esse processo? George dá alguns conselhos:
Estimar grandes pedaços de trabalho, como funcionalidades, é diferente de estimar pedaços pequenos como histórias. Nós humanos temos dificuldade para estimar consistentemente trabalhos que variam muito em dimensão. Nunca vi a soma das estimativas de histórias de funcionalidade se correlacionar com a estimativa da funcionalidade inteira.
Por essa razão, sugiro tratar funcionalidades de forma separada. Tipicamente uso "tamanho de camisetas" para estimar funcionalidades, uma vez que muito pouco é conhecido a respeito delas, fazendo com que estimativas numéricas sempre pareçam indevidamente precisas. Com relação a histórias prefiro somente contá-las. Elas têm tamanhos diferentes, claro. Mas na minha experiência, é mais fácil agrupá-las por tamanhos similares - examinando os critérios de aceite necessários para verificá-las - do que estimá-las com valores numéricos de forma consistente.
Mike Cohn publicou em seu blog Atribuindo pontos a histórias no momento certo - ou não", que existem duas razões principais para estimar o backlog do produto:
Primeiro, estimar os itens de backlog permitem ao product owner priorizar o backlog de produto. A estimativa representa o custo de um item. Sem saber o custo, o product owner não pode priorizar corretamente.
A segunda razão para estimar é que podem ser feitas projeções em longo prazo sobre o projeto. Se o cliente, por exemplo, quiser saber quando um conjunto de itens de backlog será finalizado, esses itens precisam ser estimados. De forma similar, se o cliente quiser saber quanto pode ser entregue em três meses, então aproximadamente três meses de esforço precisam ser estimados.
Fazer estimativas só no jogo do planejamento (planning game) é tarde demais, segundo Mike:
Saber o motivo para se estimar itens do backlog também pode ajudar a resolver um problema cada vez mais comum: estimar o backlog no prazo certo. O backlog do produto precisa ser estimado o mais cedo possível, de forma que o product owner possa priorizar ou responder as questões citadas sobre quando e quanto será entregue.
Colocar pontos em histórias do backlog durante o planejamento do sprint é simplesmente muito tarde para gerar benefícios. Há outros problemas em atribuir pontos durante o planejamento, mas atribuí-los tão tardiamente não permite que o product owner obtenha a vantagem da nova informação no momento que e o sprint está sendo planejado.
No artigo da ACM "Histórias não ajudam usuários", William Hudson cita um problema que ele vê quando o planejamento de novas versões tem como base somente histórias:
No XP, as histórias têm como objetivo alimentar o jogo de planejamento […]. Mas se uma equipe vai estimar e planejar com base em histórias, precisa ao menos saber o que deve ser feito e como. Isso é verdade especialmente em sistemas novos, em que não existem certas práticas já estabelecidas para serem descritas.
Isso significa que precisamos fazer alguma reflexão sobre o propósito, a forma e o tamanho do sistema antes de escrever as histórias. Infelizmente, muitos seguidores de métodos ágeis acreditam que o design do software é nocivo, embora isso não seja o que o Manifesto Ágil e seus "Doze princípios de software ágil" dizem (fazer design pesado prematuramente é ruim, mas um fazer um esboço do design não é). Portanto, estimativas e planejamento feitos com histórias criadas prematuramente podem não ser confiáveis.
Steve Povilaitis escreveu sobre como gerenciar grandes programas corporativos com funcionalidades. Ele explica alguns dos benefícios que podem ser obtidos utilizando funcionalidades no planejamento da nova versão:
Funcionalidades precisam escalar, porque é muito difícil gerenciar grandes programas/iniciativas com histórias. O planejamento de uma nova versão se torna muito detalhada se não existe uma camada intermediária de funcionalidades representando o que está se tentando construir.
Sem funcionalidades perde-se a capacidade de coordenação efetiva entre as equipes e fica impossível fornecer contexto suficiente sobre o nível de valor e as metas. Funcionalidades são necessárias para definir o produto, coordenar e planejar o que será construído pela equipe de entrega.
Michael Carew escreveu no post Estimativa ágil: se a camisa cabe. . .", sobre estimar por temas, épicos e histórias. Na fase inicial de descobertas, Michael sugere duas possíveis abordagens. Uma é para estimar usando tamanhos de camisetas e outra forma é estimar usando as Unidades de Desenvolvimento Ágil:
Uma Unidade de Desenvolvimento Ágil (Agile Development Unit - ADU) é uma equipe Scrum para um sprint, incluindo o suporte. Ela é usada dar uma noção inicial da quantidade de recursos necessários. Em alguns casos as ADUs são adquiridas e o trabalho pode ser adaptado caber nessas ADUs, uma forma de definir o que pode ser feito com o que se tem disponível.
Estimativas com base tanto em tamanhos de camisas quanto em ADUs nos dizem algo sobre a quantidade de trabalho e não sobre a duração do mesmo. Essas estimativas são usadas em decisões de negócio durante o planejamento da versão (release) :
Nesse ponto temos uma estimativa que não é baseada numa inspeção muito profunda, mas sim sobre o tamanho relativo com base em experiências anteriores. Isso nos permite atualizar o planejamento de entrega conforme o último trabalho estimado. Com base na prioridade atribuída pela área de negócio através do product owner, podemos começar a dividir os temas e épicos em histórias.
Histórias de usuários são estimadas com pontos de histórias. Michael sugere confrontar essas estimativas com estimativas anteriores, por exemplo, usando uma tabela de tamanhos de camisetas e tamanho de pontos de história:
As histórias devem ser examinadas para verificar se há alguma relação inesperada entre as várias estimativas para a história. Caso isso ocorra, significa que existe algum mal-entendido. Identificar o problema nesse momento significa verificar se a área de negócio classificou uma história com um tamanho "P" (pequeno), por exemplo, e durante a organização do backlog foi classificada como "15". Isso indica que existe entre as duas partes uma diferença de entendimento. O próximo passo é discutir essa discordância.
O último passo para uma equipe é fazer a estimativa de horas:
Durante o planejamento do sprint passamos de pontos de história para horas e determinamos se estamos usando horas reais ou ideais. Tipicamente, uma equipe estima em horas ideais e converte para horas reais usando um fator de conversão. Para calcular esse fator, deve-se confrontar as horas planejadas com as horas reais conforme o Sprint evolui.