Ao trabalhar em um projeto Agile, a equipe planeja o trabalho para os próximos sprints criando histórias. Uma história define uma única atividade encapsulada em funcionalidade com descrição e critérios de aceitação.
Os sprints geralmente duram de duas a quatro semanas. Nesse período, a equipe precisa entender quanto conteúdo pode levar em um sprint para que ainda possa fazê-lo dentro do tempo de sprint determinado.
Em um projeto não ágil, você estimaria o trabalho normalmente em homens-dia. Isso significa quantos funcionários em tempo integral você precisa para concluir esta atividade? Nesse caso, você sempre pensa nos dias e na quantidade de pessoas ao criar estimativas.
Em um projeto ágil, as coisas são diferentes. Você não conta mais dias ou pessoas para calcular a estimativa final. Na verdade, devemos proibir até mesmo calcular o esforço em algo como homens-dia. Em vez disso, você permite que a equipe converta para um valor geralmente aceito para a história que representará a estimativa geral.
Agora, para qual é exatamente o valor, isso realmente não importa. É verdade que o representante mais comum das estimativas de histórias são os Story Points. Esses são basicamente números de Fibonacci começando em 0, 1, 2, 3, 5, 8, 13, 21, etc. O próximo valor é uma soma dos dois números anteriores. Isso ajudará a diferenciar a complexidade geral da história, pois cada próximo número maior é significativamente maior que o anterior.
Mas você não precisa se ater aos pontos da história. Pode ser estimativas de tamanho de camiseta (XXS, XS, S, M, L, XL, XXL). Se você quiser ser realmente criativo, pode introduzir animais do ZOO e usá-los para estimar o tamanho.
De qualquer forma, agora é muito mais sobre o sentimento de toda a equipe sobre qual número (ou animal) representa melhor a complexidade geral dessa história em particular. Definitivamente não é sobre representação de tempo. No final, a equipe deve concluir cada história incluída no sprint dentro desse sprint. Portanto, o tempo já é dado no início e é um número constante.
últimas postagens
Componentes da estimativa de Story Points
Uma estimativa de ponto de história não é absolutamente apenas sobre quão complexa/difícil é uma história em particular. Ao estimar uma história, a equipe deve considerar vários aspectos e refleti-los no valor da estimativa final.
A estimativa final é então um valor que representa uma combinação de todos os aspectos formados em um único número. Aqui está o que tal estimativa deve incluir.
#1. Dificuldade Técnica
Assumindo que estamos estimando histórias para uma equipe de desenvolvimento, a dificuldade técnica da história será uma das primeiras áreas em que a equipe se concentrará por padrão.
E esta é, sem dúvida, a abordagem correta. A equipe cheia de especialistas técnicos deve saber avaliar melhor essa área de uma história. Aqui a equipe pode considerar várias abordagens ou dicas, como:
- Como esta história se compara a outras já entregues do ponto de vista da complexidade técnica?
- Quantos arquivos de código a equipe terá que criar/atualizar para completar a história?
- Quantas alterações de código adicionais essa história gerará nos processos do sistema circundante?
- Quão complexo será o algoritmo ou a lógica do processo para implementar?
#2. Dependências Externas e Riscos
Alguém ficaria surpreso, mas na maioria das vezes, o sucesso das histórias dentro do sprint da equipe depende de contribuições de outras equipes ou pessoas externas à própria equipe.
Histórias em que tudo o que a equipe pode realizar por conta própria é o mais fácil de estimar. As coisas ficam complicadas se a equipe precisar de ajuda externa para suas histórias. Para pessoas de fora da equipe, essa atividade não será uma prioridade, naturalmente. A equipe só tem que contar com esse fator e considerá-lo dentro da estimativa.
O quanto esse fator aumentará na estimativa total dependerá principalmente da experiência anterior da equipe e do “nível de externalidade”. Normalmente, em alguns sprints, a equipe estabelecerá algum sentimento unificado natural de quanto essa dependência de pessoas externas pode complicar a conclusão bem-sucedida da história.
#3. Fator de reutilização
A próxima área a considerar é quanto do conteúdo existente a equipe pode reutilizar para concluir a história. Obviamente, se algumas das partes já estão presentes de uma forma ou de outra, não é necessário construí-lo do zero. Em vez disso, a equipe pode reutilizar a solução já criada para criar uma nova com muito mais rapidez.
Dessa forma, esse conhecimento pode diminuir a estimativa total, mesmo que normalmente (sem essa reutilização), a história fosse mais complexa com base no conteúdo definido.
#4. Compreensão da Própria Equipe
Um fator notável que nenhuma estimativa baseada em dias-homem pode considerar é o autoconhecimento da capacidade e senioridade da equipe.
À medida que a equipe trabalha em conjunto e realiza vários sprints, as pessoas de dentro vão se conhecendo. Eles vão começar a entender quem sabe o quê e o quão bom ele/ela é nisso. E uma vez que todos conheçam o resto da equipe, eles juntos como uma equipe podem considerar isso durante a estimativa.
Se a história for pesada em alguma habilidade técnica concreta e essa habilidade estiver fortemente presente dentro da equipe, é claro que a realização da história não será tão complicada. Ou vice-versa, se faltar a habilidade necessária em toda a equipe, a equipe precisará de muito mais tempo para entrar no tópico e deve refletir isso na estimativa.
Estimando a história
Cada estimativa de história deve ser um esforço de equipe. Nenhuma voz única deve predefinir a complexidade da história. O objetivo final deve ser permitir que a equipe discuta a estimativa até que todos os membros concordem com um único valor que representará a estimativa final.
A equipe pode fazer a estimativa diretamente durante a discussão de refinamento do sprint (uma reunião onde as histórias são discutidas e esclarecidas entre a equipe) ou, alternativamente, pode reservar um tempo dedicado para fazer exatamente isso.
Exemplo de processo de estimativa
Compromisso do Plano de Sprint
A equipe agora tem um backlog com histórias que já passaram pelas sessões de estimativa. Idealmente, as histórias foram atribuídas (além do valor da estimativa final) também como prioridade para que a equipe saiba quais histórias virão a seguir no próximo sprint.
Aí vem a sessão de planejamento, onde a equipe escolherá algumas das histórias para o próximo sprint. A decisão sobre quais histórias escolher deve ser baseada no seguinte:
✅ Histórias com as maiores prioridades que a equipe considera primeiro.
✅ Uma experiência da equipe de quantos pontos de história eles são capazes de terminar em um sprint. Esse conhecimento só vem com o tempo e a experiência da equipe. Você precisa de vários sprints para ajustar e obter uma compreensão adequada desse recurso.
✅ Você não deve considerar apenas o número total de pontos da história e a prioridade. Outra consideração é como as habilidades dentro da equipe se espalharão pelas histórias selecionadas. Por exemplo, se a equipe tiver apenas dois desenvolvedores de front-end, eles podem não escolher apenas histórias que consistem apenas em desenvolvimento de front-end. Isso levaria à superutilização dos dois caras, enquanto o resto da equipe não é tanto. Portanto, o conhecimento da equipe anda de mãos dadas com a eficácia da criação do conteúdo do sprint.
Fator de Velocidade
Acima de tudo está a velocidade da equipe (para o próximo sprint). Esse número não está relacionado à quantidade total de pontos de história de forma alguma. No entanto, indica o quanto a equipe estará disponível para trabalhar no próximo sprint.
Para poder planejar com precisão o conteúdo de um sprint, juntamos os dois aspectos:
Leva tempo e prática para encontrar o ponto ideal.
Benefícios e erros comuns
É surpreendente o quanto as equipes estão dispostas a complicar para si mesmas o processo de transformação para uma equipe ágil. Literalmente, parece que você precisa “pegar” antes de começar a trabalhar nesse modo.
Este primeiro passo é, infelizmente, também o mais difícil. Em alguns casos, leva até anos, principalmente em ambientes corporativos estritamente conservadores, onde o tempo sozinho fica parado no tempo.
De qualquer forma, isso é o que acontecerá quando a equipe “pegar”:
- Você não precisa mais calcular pessoas ou dias para saber quando algo pode ser concluído.
- A equipe aprenderá a criar histórias tão complexas quanto possível para que caibam dentro de um sprint. Se uma história for mais complexa, ela será dividida automaticamente em mais histórias.
- A equipe tem boas estimativas de cada parte do trabalho e, depois de planejá-lo para um sprint, você sabe exatamente quando é o prazo.
- Isso aumentará a confiabilidade e a previsibilidade da equipe.
- Todas as pessoas dentro da equipe estarão “na mesma frequência”. Eles vão olhar para uma história e vão entender coisas semelhantes. Talvez depois de algum tempo, eles nem se preocupem em estimar. Eles veem o número em suas cabeças e, como todos veem o mesmo número, podem se comprometer com histórias em um sprint mesmo sem essa estimativa explícita.
E é isso que geralmente acontece se a equipe ainda não consegue entender o processo ou a forma de trabalhar:
- De alguma forma, eles ainda se apegam às estimativas antiquadas de homens-dia. Eles convertem tudo em dias ou pessoas envolvidas. Pontos de história ou números de Fibonacci significam quantidade de dias, direta ou indiretamente, por meio de várias transformações.
- A liderança compara as equipes com base no número de pontos da história entregues a cada sprint. Isso é o mais errado possível. Um fato substancial não é compreendido: cada equipe estima os pontos da história de maneira diferente. Não há absolutamente nenhuma razão para fazer um esforço para sincronizar duas equipes para estimar suas histórias da “mesma maneira”.
- Enquanto o ponto da história de uma equipe significa desenhar um círculo, para outra equipe pode significar desenhar uma casa com telhado plano, quatro janelas e duas portas. E está tudo bem.
- Às vezes, as equipes tendem a estimar quase tudo entre dois a quatro números diferentes. Talvez por temerem que uma história tenha o número 123, alguém pensará que tem algo a ver com o número de dias. Mas o fato é que a escala de Fibonacci tem uma quantidade infinita de números. Não precisamos nos limitar apenas a estimativas de 3, 5 ou 8. Certamente podemos (e talvez criemos as histórias já com esse propósito em mente para serem tão complexas, caso em que isso é bom), mas nós definitivamente não precisa.
- A estimativa é conduzida por pessoas seniores que predefinirão a expectativa de todo o grupo. Nunca devemos permitir que um membro da equipe influencie a estimativa. Todos têm o mesmo direito de expressar sua opinião e ser ouvidos.
Palavras Finais
Mudar para a estimativa ágil das abordagens mais tradicionais nem sempre é fácil e demora para acomodar, tanto para as equipes quanto para a liderança acima. Para que funcione, ambos os lados devem entender o processo. Se um deles não entender, o período de transição é um caminho difícil e cheio de expectativas contraditórias.
Mas quando tudo se transformar, algumas coisas mágicas começarão a acontecer. As equipes poderão estimar e planejar melhor seu trabalho, e a liderança terá lançamentos e roteiros mais previsíveis nos quais confiar.
Em seguida, confira processos não saudáveis que podem arruinar seu sprint.