No mundo ágil, estimativas são como bússolas que guiam as equipes de desenvolvimento em direção a entregas bem-sucedidas. Neste texto, falaremos os principais aspectos relacionados a estimativas, desde a definição de velocidade e capacidade até técnicas para estimar o tamanho do trabalho.

Definindo velocidade e capacidade

A velocidade e a capacidade de um time Scrum são métricas cruciais para estimar o tamanho e o tempo necessário para concluir um projeto. Aqui estão os principais pontos sobre esses conceitos:

1. Velocidade e capacidade: A velocidade de um time é a quantidade de pontos de história que ele entrega por sprint. A capacidade é a quantidade máxima de pontos que o time pode absorver por sprint. Ambas estão inter-relacionadas e ajudam a prever o progresso e a duração do projeto.

2. Medição da velocidade: A velocidade é medida com base na experiência prática passada, geralmente após 1 a 3 sprints. A velocidade pode variar devido a fatores como mudanças na equipe ou no projeto, por isso é importante monitorá-la continuamente.

3. Importância da velocidade: Conhecer a velocidade do time permite fazer previsões mais precisas sobre a conclusão do projeto. A velocidade deve ser comparada com o próprio time e não com outros times, pois é única para cada equipe.

4. Sprints e tamanho: As sprints devem ter um tamanho consistente para que a métrica de velocidade seja válida. Se o time entrega, por exemplo, 80 pontos por sprint, pode-se estimar que um projeto de 1000 pontos levará aproximadamente 13 sprints (ou 39 semanas).

5. Times novos: Times recém-formados ou inexperientes podem não ter uma velocidade definida inicialmente. Nesse caso, devem começar com uma estimativa e ajustar a velocidade com base na experiência das primeiras sprints.

6. Ajustes contínuos: É normal ajustar a velocidade e a capacidade conforme o time ganha experiência e enfrenta novos desafios ao longo do projeto.

Esses conceitos ajudam a melhorar a previsibilidade e a gestão dos projetos ágeis, proporcionando uma base sólida para planejamento e ajustes contínuos.

Pontos de história

Os pontos de história são unidades subjetivas utilizadas por times ágeis para estimar o esforço e a complexidade de histórias de usuário. Eles representam a quantidade de esforço necessário para implementar uma história, focando na complexidade da tarefa sem incluir interrupções. Pontos de história são baseados em medidas relativas, comparando uma história com uma história padrão previamente estimada. A sequência de Fibonacci é comumente usada para essas estimativas devido à sua natureza não linear, que evita a tentação de usar a regra de três para calcular horas de trabalho. Isso tende a ser mais assertivo do que estimar isoladamente cada item.

Ao usar pontos de história, o foco está no valor entregue, não no esforço despendido. As estimativas são feitas durante as reuniões de refinamento e planejamento da sprint, baseando-se na priorização do Product Owner. Para começar, escolhe-se uma história padrão e atribui-se um valor a ela; outras histórias são então comparadas com esse padrão para determinar seus pontos de história. Esses pontos ajudam a entender e planejar o esforço necessário para concluir as histórias de usuário, melhorando a gestão e previsibilidade dos projetos ágeis.

Sprint planning

A Sprint Planning é uma reunião crucial no framework Scrum, realizada no início de cada sprint. Seu principal objetivo é definir o trabalho que será realizado durante a sprint e como ele será executado. Na primeira parte da reunião, o Product Owner apresenta as histórias de usuário mais prioritárias do backlog do produto, e, junto com a equipe de desenvolvimento, decide quais itens serão incluídos na sprint. A equipe precisa entender claramente os requisitos e os critérios de aceitação de cada história selecionada. Na segunda parte, a equipe de desenvolvimento planeja como transformar essas histórias em incrementos funcionais de software, decompondo-as em tarefas menores, estimando o esforço necessário e atribuindo responsabilidades.

A Sprint Planning é fundamental para a estimativa de trabalho, pois é nesse momento que a equipe analisa as histórias de usuário em detalhe e faz as estimativas de esforço. Esse processo permite que a equipe identifique possíveis desafios e necessidades de recursos, garantindo que todos tenham uma visão clara e realista do trabalho a ser realizado. As estimativas de esforço são essenciais para o planejamento e a execução eficiente da sprint, ajudando a garantir que os objetivos sejam alcançados dentro do prazo e com a qualidade esperada. Ao final da Sprint Planning, todos os membros da equipe devem estar alinhados sobre o que será entregue e como o trabalho será realizado, proporcionando uma base sólida para a colaboração e o sucesso da sprint.

Técnicas para estimar o tamanho de um trabalho

Abaixo listarei algumas técnicas para ajudar na estimativa de trabalho

T-shirt

A técnica T-Shirt é uma abordagem simples e intuitiva para estimar o tamanho do trabalho em projetos ágeis, utilizando categorias de tamanhos de camisetas, como Pequeno (S), Médio (M), Grande (L), Extra Grande (XL) e assim por diante. Em vez de tentar determinar um número exato de pontos para cada tarefa, a equipe de desenvolvimento classifica as histórias de usuário em uma dessas categorias com base na percepção do esforço necessário. Essa técnica facilita a comunicação e a compreensão das estimativas, permitindo uma comparação relativa entre diferentes tarefas sem a necessidade de precisão numérica. Ao final do processo, essas categorias podem ser convertidas em pontos de história para um planejamento mais detalhado.

Magic estimation

A técnica Magic Estimation é um método rápido e colaborativo para estimar o tamanho do trabalho em projetos ágeis. Os membros da equipe dispõem as histórias de usuário em uma linha de tempo ou escala visualmente, sem discussões iniciais, e depois ajustam as posições com base em um consenso coletivo. Essa abordagem eficiente elimina longas discussões, promove a participação de todos e facilita a obtenção de estimativas compartilhadas, melhorando o planejamento e a execução das sprints.

Planning poker
A técnica Planning Poker é uma prática comum em metodologias ágeis para estimar o tamanho do trabalho de forma colaborativa e baseada no consenso da equipe. Durante uma sessão de Planning Poker, cada membro da equipe recebe um conjunto de cartas com valores de pontos de história, geralmente baseados na sequência de Fibonacci (como 1, 2, 3, 5, 8, 13, etc.). O Product Owner ou facilitador apresenta uma história de usuário, e os membros escolhem uma carta que representa sua estimativa individual para o esforço necessário. As estimativas são então reveladas simultaneamente, permitindo discussões rápidas e focadas em casos de divergência significativa. Esse método não apenas ajuda a obter uma estimativa mais precisa do trabalho, mas também promove a colaboração e o entendimento compartilhado dentro da equipe.

Horas x Pontos de história

Os pontos de história são eficazes para estimar o tamanho relativo das tarefas de desenvolvimento, mas podem ser inadequados para previsões precisas de tempo de entrega futuro. Por isso, muitas equipes convertem pontos de história em horas estimadas de esforço para ter uma visão mais detalhada do trabalho. Por exemplo, uma equipe pode estabelecer que 10 pontos de história equivalem a aproximadamente 8 horas de esforço. Essa conversão não precisa ser exata inicialmente, pois é comum que a equipe ajuste suas estimativas à medida que ganha mais experiência e compreende melhor o esforço necessário. Estabelecer uma equivalência simples entre pontos de história e horas de esforço permite que a equipe tenha um contraponto útil durante o planejamento do projeto, facilitando decisões e ajustes conforme necessário.

Definição de pronto X Definição de preparado

A definição de pronto no Scrum é um conjunto formal de critérios que uma história de usuário deve satisfazer para ser considerada concluída. Estes critérios incluem desde a conclusão de testes unitários e de qualidade até a demonstração para as partes interessadas. A definição de pronto assegura a qualidade e o valor do incremento entregue, sendo criada e mantida pelo time Scrum para garantir consistência e eliminar ambiguidades ao longo do projeto. Por outro lado, a definição de preparado, ou "ready", refere-se à condição em que uma história está clara e pronta para ser desenvolvida dentro do timebox da sprint, com critérios de aceitação bem definidos para validar sua implementação conforme as expectativas do Product Owner.

No próximo texto sobre gerenciamento de projetos ágeis iremos falar sobre sprints e sobre como executá-la.