Estimativa de História de Usuário – Tabela de Afins

Como estimar histórias de usuário para desenvolvimento ágil

Estimar uma história de usuário é difícil! Como podemos obter a melhor estimativa do tamanho de uma história? Algumas pessoas dizem que o melhor tamanho deve ser estimado em termos de pontos de história, e outras preferem que sejam estimados em termos de horas ou dias.

Bem, estimar é definitivamente difícil, mas existem alguns conceitos que podem nos ajudar no processo de estimativa de histórias de usuário:

1. Estime histórias de usuário em termos relativos a partir de dois aspectos
   • Esforço de trabalho
   • Risco (por exemplo, complexidade e incerteza)
2. Estime histórias de usuário usando pontos de história
3. Coloque essas histórias de usuário na tabela de afins em que você tem maior confiança na estimativa em termos de esforço de trabalho e complexidade (risco)
4. Estime gradualmente as outras histórias menos familiares em termos de esforço de trabalho e complexidade, comparando-as com as histórias que já foram estimadas na tabela de afins.

Afins de Histórias de Usuário para Estimativa

A estimativa de uma história de usuário nunca pode ser 100% precisa e, na verdade, nenhum método consegue alcançar isso. Para melhorar a precisão da estimativa, começamos decidindo o tamanho do sprint (por exemplo, duas semanas ou 10 dias úteis) e realizamos a estimativa em algumas histórias de usuáriocom as quais nos sentimos mais confortáveis em termos de estimativa (por exemplo, 5 dias e a certeza é média). Neste caso, você colocará a história no meio verticalmente (certeza ou risconível) e horizontalmente (esforço de trabalho esforçoé igual a 5 dias, ou metade do comprimento do sprint, que é de 10 dias). Você pode então usá-lo como ponto de referência na estimativa das outras histórias de usuário. Pergunte a si mesmo se esta história de usuário exige mais esforço do que a referência, ou menos, e tem mais incerteza ou menos. À medida que você coloca mais histórias na Tabela de Afins, pode comparar várias histórias para verificar se a distribuição é lógica ou não, e então ajustá-las para torná-las justas. O processo é um pouco mais uma arte do que uma engenharia. Faça isso e discuta na reunião da equipe, em vez de qualquer confronto. A precisão geralmente melhora conforme a equipe se torna mais madura.

Como a Tabela de Afins calcula? (Assista a um Vídeo) 

Para entender como os pontos de história e os dias são estimados automaticamente na Tabela de Afins, precisamos entender que as grades horizontais representam os esforços de trabalho, aumentam da esquerda para a direita, e a complexidade do desenvolvimento da história (por exemplo, nova tecnologia, novo domínio, etc.) aumenta do topo para a parte inferior.

Como o número máximo de dias para o desenvolvimento de uma história de usuário deve ser no máximo o comprimento do sprint (caso contrário, a história de usuário é muito grande e precisa ser dividida, ou o sprint está definido muito curto, o que exige uma extensão), então o número de dias da grade inferior direita também deve ser igual ao comprimento do sprint. Com base nesta suposição, a estimativa da história pode ser calculada automaticamente.

Observe que: No primeiro exemplo acima

Ponto de História = Esforço x Risco (por exemplo, 3 x 4 = 12)

Unidade de Ponto de História = Número Total de Pontos / Comprimento do Sprint (por exemplo, 100 / 20) = 0,2

Dias (horas) da História = Ponto de História / Unidade de Ponto de História (por exemplo, 12 x 0,2) = 2,4

Elimine Riscos com o Spike do Projeto

De acordo com o Dicionário Ágil, a definição de Spike é:

“Uma tarefa voltada para responder a uma pergunta ou coletar informações, em vez de produzir umproduto. Às vezes, uma história de usuário é gerada que não pode ser bem estimada até que a equipe de desenvolvimento faça algum trabalho real para resolver uma questão técnica ou um problema de design. A solução é criar um “spike”, que é algum trabalho cujo propósito é fornecer a resposta ou solução.”

Ao estimar uma história de usuário, não consideramos apenas o esforço de desenvolvimento, mas também levamos em conta os riscos e incertezas envolvidos. Muitas vezes, um spike é criado antes do início formal de um sprint para gerenciar o trabalho necessário para ser realizado, a fim de que outras histórias de usuário possam ser estimadas de forma justa.

Baixe e Experimente Agora!