Em projetos que utilizam a metodologia Agile, o planejamento das atividades para os próximos sprints é realizado através da criação de histórias de usuário. Cada história representa uma funcionalidade específica, detalhada por uma descrição e critérios de aceitação bem definidos.
Os sprints geralmente têm duração de duas a quatro semanas. Durante esse período, a equipe precisa avaliar a quantidade de trabalho que pode assumir para garantir que será concluído dentro do prazo estabelecido para o sprint.
Em projetos que não seguem a metodologia Agile, a estimativa de trabalho é comumente feita em termos de homens-dia, ou seja, quantos funcionários em tempo integral seriam necessários para completar a tarefa. Nesse modelo, o foco está sempre na duração em dias e na quantidade de pessoas.
Em projetos ágeis, a abordagem é diferente. Não se calcula mais o tempo ou o número de pessoas para chegar a uma estimativa final. Na verdade, a ideia de estimar o esforço em homens-dia deve ser evitada. Em vez disso, a equipe utiliza uma métrica aceita para representar o esforço necessário para cada história.
A métrica exata não é o mais importante. A mais utilizada são os Story Points, que geralmente seguem a sequência de Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21… Cada número é a soma dos dois anteriores. Essa escala ajuda a diferenciar a complexidade das histórias, já que cada número subsequente é significativamente maior que o anterior.
No entanto, não é obrigatório usar Story Points. Pode-se estimar usando tamanhos de camisetas (XXS, XS, S, M, L, XL, XXL) ou, de forma mais criativa, utilizar nomes de animais de um zoológico como referência.
O essencial é que a equipe, como um todo, defina qual valor (ou animal) representa melhor a complexidade de cada história. Essa estimativa não está relacionada ao tempo. O prazo do sprint já está definido e é constante. O objetivo é que todas as histórias incluídas sejam finalizadas dentro desse período.
Componentes da Estimativa de Story Points
A estimativa de Story Points não se resume apenas à complexidade ou dificuldade de uma história. Ao estimar, a equipe precisa considerar diversos fatores que influenciam o valor final.
A estimativa final representa uma combinação de todos esses aspectos, expressa em um único número. Abaixo, os principais componentes dessa estimativa:
#1. Dificuldade Técnica
Quando se trata de estimar histórias para uma equipe de desenvolvimento, a dificuldade técnica da história é uma das primeiras áreas de atenção.
Essa é uma abordagem correta, pois os especialistas técnicos da equipe são os mais capacitados para avaliar essa dimensão. A equipe pode considerar:
- Comparar a complexidade técnica da história com histórias já finalizadas.
- Quantos arquivos de código serão criados ou alterados para completar a história.
- Quantas mudanças essa história pode gerar nos processos do sistema.
- A complexidade do algoritmo ou da lógica a ser implementada.
#2. Dependências Externas e Riscos
O sucesso de uma história muitas vezes depende da colaboração de outras equipes ou pessoas que não fazem parte da equipe. Histórias que podem ser concluídas de forma independente são mais fáceis de estimar. A situação se complica quando a equipe precisa de ajuda externa.
Para pessoas de fora da equipe, a prioridade é diferente, e a equipe precisa levar esse fator em consideração na estimativa. O impacto na estimativa dependerá da experiência anterior da equipe e do “nível de externalidade”. Com o tempo, a equipe adquire um entendimento sobre como essa dependência afeta a complexidade da história.
#3. Fator de Reutilização
Outro aspecto relevante é o quanto a equipe pode reutilizar conteúdos já existentes para completar a história. Se partes da solução já foram criadas, não é necessário começar do zero. A reutilização acelera a criação da nova solução.
O conhecimento da existência de componentes reutilizáveis pode diminuir a estimativa total, mesmo que a história fosse, em condições normais, mais complexa.
#4. Compreensão da Própria Equipe
Um fator que estimativas baseadas em homens-dia não consideram é o autoconhecimento da capacidade e senioridade da equipe.
À medida que a equipe trabalha junta em vários sprints, cada membro começa a entender as habilidades e pontos fortes de cada colega. Essa compreensão mútua permite considerar essas características na hora de estimar.
Se uma história exige uma habilidade técnica que é forte na equipe, a sua conclusão será menos complexa. Caso contrário, se faltar essa habilidade, a equipe precisará de mais tempo para dominar o assunto, o que deve ser refletido na estimativa.
Estimando a História
A estimativa de cada história deve ser um esforço colaborativo da equipe. Nenhuma voz deve definir a complexidade da história sozinha. O objetivo é que a equipe discuta e chegue a um consenso sobre o valor final da estimativa.
A estimativa pode ser feita durante a reunião de refinamento do sprint, onde as histórias são discutidas e esclarecidas, ou em uma sessão dedicada a essa atividade.
Exemplo de Processo de Estimativa
- Escolha uma ferramenta de estimativa, como Planning Poker ou um quadro do Miro.
- Apresente a história à equipe, permita uma discussão e tire as dúvidas. Garanta que todos estejam prontos para estimar.
- Inicie a estimativa, solicitando que cada membro escolha um número da escala de Fibonacci.
- Após todos estimarem, observe os resultados e inicie a discussão. Geralmente, as estimativas se concentram em dois ou três números. Peça que aqueles que estimaram o valor mais baixo expliquem seu raciocínio, e da mesma forma, aqueles que estimaram o valor mais alto. O objetivo é apresentar todas as considerações e fatos para que todos entendam a história.
- Após a discussão, peça para a equipe estimar novamente. As estimativas tendem a convergir para um ou dois números distintos. Repita a discussão, se necessário. A estimativa termina quando todos concordam com o valor final.
- A estimativa deve ser um consenso da equipe, não apenas de alguns indivíduos. Como cada história pode ser atribuída a qualquer membro da equipe, todos precisam concordar com a complexidade da história.
Compromisso do Plano de Sprint
A equipe tem agora um backlog com as histórias estimadas. Idealmente, as histórias também foram priorizadas, permitindo que a equipe defina quais histórias serão trabalhadas no próximo sprint.
Durante a sessão de planejamento, a equipe decide quais histórias serão incluídas no próximo sprint, com base em:
- ✅ Histórias de maior prioridade, que são analisadas primeiro.
- ✅ A experiência da equipe sobre quantos pontos de história eles conseguem entregar em um sprint. Isso se desenvolve com o tempo e a experiência, exigindo vários sprints para ajustar a capacidade.
- ✅ O equilíbrio de habilidades dentro da equipe entre as histórias selecionadas. Por exemplo, se a equipe tiver apenas dois desenvolvedores de front-end, não é ideal escolher apenas histórias de front-end, sobrecarregando esses dois membros enquanto o resto da equipe fica com pouco trabalho. A distribuição de habilidades na equipe deve ser considerada na criação do conteúdo do sprint.
Fator de Velocidade
Além disso, a velocidade da equipe (para o próximo sprint) deve ser considerada. Esse número indica o quanto a equipe estará disponível para trabalhar no próximo sprint e não está diretamente relacionado à quantidade total de pontos de história.
Para planejar o conteúdo do sprint com precisão, é preciso considerar dois aspectos:
- Velocidade da equipe: medida em dias. Cada membro da equipe disponível por um dia completo equivale a um ponto na velocidade da equipe. Por exemplo, uma equipe de 10 pessoas totalmente disponível por um sprint de duas semanas tem uma velocidade de 100.
- Quantidade de pontos de história concluídos por sprint: medida em pontos de história, com base na experiência da equipe e na sua velocidade.
Encontrar o equilíbrio ideal exige tempo e prática.
Benefícios e Erros Comuns
É surpreendente como as equipes tendem a complicar a transição para a metodologia Agile, como se fosse necessário “pegar o jeito” antes de começar a trabalhar dessa forma.
Esse primeiro passo é o mais difícil, e em alguns casos, pode levar anos, especialmente em ambientes corporativos conservadores.
Quando a equipe “pega o jeito”:
- Não é preciso calcular pessoas ou dias para saber quando algo será concluído.
- A equipe aprende a criar histórias que se encaixem dentro de um sprint. Se a história for muito complexa, ela é dividida em histórias menores.
- A equipe tem boas estimativas de cada parte do trabalho e sabe o prazo de entrega do sprint.
- A confiabilidade e previsibilidade da equipe aumentam.
- Todos os membros da equipe estão na mesma “frequência”. Eles entendem a complexidade da história da mesma forma. Com o tempo, a estimativa pode nem ser necessária. Ao verem a história, todos entendem sua complexidade de forma semelhante e podem se comprometer com ela sem a estimativa explícita.
O que acontece se a equipe não consegue entender o processo:
- A equipe ainda se apega às estimativas em homens-dia, convertendo os pontos de história em dias ou pessoas.
- A liderança compara equipes com base no número de pontos de história entregues por sprint. Esse é um erro grave, pois cada equipe estima os pontos de história de forma diferente e não é necessário sincronizar as estimativas de diferentes equipes.
- O que para uma equipe significa desenhar um círculo, para outra pode significar desenhar uma casa com teto plano, quatro janelas e duas portas. E tudo bem.
- As equipes tendem a estimar quase tudo entre dois a quatro números, talvez com medo de que o número 123 seja associado a dias. Mas a escala de Fibonacci tem uma quantidade infinita de números, e não é necessário se limitar a 3, 5 ou 8. As histórias podem, inclusive, serem criadas para terem maior complexidade e, consequentemente, valores maiores na escala de Fibonacci.
- A estimativa é conduzida pelos membros mais experientes da equipe, que predefinem as expectativas de todo o grupo. É fundamental que todos tenham o mesmo direito de expressar suas opiniões.
Palavras Finais
A transição para a estimativa ágil nem sempre é fácil e leva tempo para que equipes e lideranças se adaptem ao processo. É essencial que ambos os lados compreendam a nova forma de trabalho. Se um dos lados não entender, o período de transição será difícil e cheio de expectativas conflitantes.
Mas quando tudo se encaixa, as equipes são capazes de planejar melhor o trabalho, e a liderança tem lançamentos e roteiros mais previsíveis.
Em seguida, verifique os processos que podem prejudicar seu sprint.