O que é estimativa ágil?

Se uma equipe está desenvolvendo um produto ou um projeto, precisamos responder: “Quando podemos concluí-lo?” ou “Em que medida podemos entregá-lo até uma determinada data?” Assim como nos modelos tradicionais de desenvolvimento, precisamos estimar a carga de trabalho antes de iniciar um projeto.

A estimativa ágil tem as seguintes três características:

Estimativa colaborativa da equipe

Em Scrumdesenvolvimento, a equipe compartilha a responsabilidade e trabalha coletivamente para cada Sprint. Portanto, as equipes ágeis utilizam técnicas de estimativa colaborativa para estimar a carga de trabalho. A estimativa colaborativa geralmente utiliza o Planning Poker como ferramenta, onde a equipe joga um jogo de estimativa coletivamente. O Planning Poker é considerado uma das técnicas mais eficazes e envolventes para estimar o esforço em ágildesenvolvimento. Ele consiste em um conjunto de números semelhantes aos de Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Cada baralho inclui quatro conjuntos desses números de Fibonacci, projetados para uso por até quatro membros da equipe.

Precisão da estimativa em grupo versus individual

Um estudo sobre a precisão da estimativa de esforço entre indivíduos e grupos em um experimento de projeto de software revelou que 20 profissionais de software da mesma empresa estimaram separadamente o esforço necessário para implementar o mesmo projeto de software. Os participantes tinham diferentes backgrounds e funções, e o projeto de software já havia sido implementado anteriormente. Mais tarde, foram agrupados em cinco equipes. Cada equipe discutiu e combinou seus conhecimentos para concordar em uma única estimativa.

Resultado: As estimativas baseadas em discussão em grupo foram mais precisas do que as estimativas individuais.

Passos para jogar Planning Poker

1. Cada membro da equipe recebe um conjunto de cartas contendo: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ — um total de 12 cartas.
2. O Product Ownerlê a descrição da história do usuário ou funcionalidade para a equipe.
3. Os membros da equipe discutem a funcionalidade e fazem perguntas ao Product Owner, se necessário.
4. Após a discussão, cada membro seleciona uma carta representando sua estimativa e a revela simultaneamente.
5. Se as estimativas diferirem significativamente, a equipe discute: Concordamos? Que fatores foram ignorados? A pessoa com a estimativa mais alta ou mais baixa deve explicar seu raciocínio antes da próxima rodada de votação.
6. Após a discussão, a equipe pode passar por outra rodada até que seja alcançado um consenso.
7. Volte para o passo 2 e comece a estimar o próximo item da lista de backlog.

Estimar tamanho, não tempo — usar estimativa relativa em vez de estimativa absoluta

A estimativa é simplesmente uma suposição bem fundamentada. Usamos todo o conhecimento e experiência disponível para estimar quanto tempo levará. Em vez de avaliar cada novo item de trabalho isoladamente, por que não compará-lo com itens anteriormente concluídos? Os seres humanos são melhores em relacionar objetos de tamanhos semelhantes do que em adivinhar tamanhos absolutos.

Por exemplo: Está próximo a este item muito pequeno? Ou mais parecido com este projeto de tamanho médio? Ou verdadeiramente grande, como aquele que concluímos no mês passado? A estimativa relativa não apenas reduz o tempo gasto na estimativa, mas também melhora significativamente a precisão.

Nossos cérebros não são bons em estimativas absolutas — sempre relacionamos coisas novas que precisamos estimar ao que já conhecemos.

Estimativa de Pontos de História

Estimativa de Velocidade — Registro e Média da Velocidade da Equipe por Sprint

A velocidade da equipevelocidade é o número de pontos de históriaaequipe Scrumrealmente conclui em uma Sprint. A velocidade da equipe indica quão rápido a equipe trabalha. Para um novo projeto ou equipe (sem registros anteriores de velocidade), podemos realizar 1–2 Sprints para medir e estabelecer uma velocidade inicial. Durante a execução da Sprint, registramos a velocidade da equipe em cada Sprint para planejamento futuro.

Estimativa da Velocidade da História do Usuário

Estimamos o número total de pontos de história no Product Backlog. Conhecendo a velocidade média por Sprint, podemos calcular quantas Sprints são necessárias para concluir o projeto — estimando assim a duração do projeto. Como mostrado na figura abaixo.

Estimativa da Duração do Projeto Scrum