Como fazer uma estimativa Agile do jeito certo

Muitos desenvolvimentos Scrum e Agile começam com práticas básicas para permitir que as equipes cumpram melhor as prioridades de negócios. As práticas incluem se comprometer com o que as equipes podem fazer em um sprint, realizar levantamentos diários para gerenciar o trabalho em andamento, hospedar demonstrações para avaliações constantes dos interessados e organizar retrospectivas para discutir melhorias no processo.

Usando essas práticas fundamentais, equipes pequenas e ágeis podem demonstrar o valor dos negócios, fornecendo melhorias incrementais,  permitindo que as partes interessadas possam avaliar novas prioridades.

À medida que as organizações e equipes amadurecem suas práticas ágeis, muitas vezes enfrentam novas questões. Os líderes podem perguntar: “Você pode me dizer quando o recurso que priorizamos será feito?” ou “Você pode compartilhar comigo uma lista de recursos que provavelmente serão feitos nos próximos meses?” Quão caro e complexo é esse aprimoramento?”, e a equipe de operações pode querer saber:“ Você consegue encaixar essas correções de defeitos no próximo sprint? ”

As equipes que se dedicam ao aprimoramento de processos geralmente têm questões relacionadas à produtividade e à qualidade em torno de seu processo ágil. Muitas ferramentas ágeis medem a velocidade da equipe ou a quantidade as tarefas que podem ser feitas em um sprint, e as equipes vão querer definir, medir, estabilizar e, idealmente, aumentar sua velocidade. Equipes mais avançadas muitas vezes querem analisar seu desempenho geral em muitos sprints: elas oferecem uma qualidade superior quando trabalham em muitas pequenas histórias ou apenas em algumas grandes? Qual é o impacto se um membro da equipe está de licença por um longo período ou, o que mais ele pode fazer se novas pessoas forem adicionadas à equipe?

Se você estiver diante de alguma dessas perguntas, sua organização ou equipe poderá estar pronta para implementar a estimativa ágil. 

A estimativa ágil tem como objetivo atribuir um fator de custo a tudo no backlog. Essa ponderação de custo pode ser usada para medir a velocidade da equipe, tomar melhores decisões em torno da priorização de recursos ou para desenvolver previsões e roteiros.

Há algum debate sobre se implementar a estimativa ágil. Há tanto um movimento #NoEstimates e como também especialistas que extrapolam no uso de estimativas.  Se você está liderando a cobrança pela implementação de estimativas em sua organização, é importante ler esses argumentos. Levar as pessoas a estimar não é fácil, e você provavelmente encontrará pessoas que não querem participar de estimativas. Compreender o debate irá ajudá-lo a responder a sugestões ou objeções individuais ou por equipe.

A estimativa ágil exige que você apresente uma metodologia sobre como uma equipe deve desenvolver um consenso sobre a estimativa. Você pode ouvir sobre o planejamento do poker, o sistema de buckets, o mapeamento de afinidades e outras técnicas de estimativa . No meu trabalho, eu geralmente capacito as equipes para decidir como irão trabalhar juntas para chegar a suas estimativas, mas eu forneço algumas diretrizes. As estimativas devem refletir sobre o esforço e a complexidade da questão que está sendo trabalhada e devem contabilizar o trabalho de todos.

Orientações
Para dar às equipes orientações mais concretas sobre estimativas, deve haver uma discussão e um conjunto padrão para uma unidade de medida. Aqui, novamente, há algum debate sobre se estimar em horas, adotar uma medida abstrata chamada pontos de história, ou usar rótulos como tamanhos de camisetas.

Algumas equipes começam com o dimensionamento de camisetas porque é mais fácil de entender e se comunicar. Um tamanho “pequeno” é provavelmente algo mais fácil de ser comparado a um “extra grande”, e equipes, proprietários de produtos e partes interessadas podem refletir nesses termos com mais facilidade em comparação com estimativas de “dez horas” ou “oito pontos”.

Mas o uso de tamanhos de camisetas não fornece quantificação, por isso são mais difíceis de usar para medir velocidade ou realizar análises. Muitas equipes se formarão em tamanhos de camiseta conforme amadurecem suas práticas de estimativa.

As horas de esforço são boas métricas para usar quando as equipes estão executando tarefas mais padronizadas que têm baixa complexidade ou risco associado a elas. Saber que uma história para modificar a interface do usuário levará duas horas de esforço é valioso se o tipo de tarefa se presta a uma métrica precisa baseada em esforço.

Mas o desenvolvimento de software e outros processos de negócios são menos precisos, têm mais incógnitas e, muitas vezes, exigem a contribuição de várias pessoas com diferentes habilidades. Se a sua história exigir o uso de uma nova API, o desenvolvimento de um widget de front-end e a garantia de que a entrega atenda aos critérios de desempenho desejados, a história pode ser difícil de medir em horas de esforço. Há o risco de trabalhar com uma nova API e provavelmente há coordenação entre duas ou mais pessoas para implementar o código e os casos de teste.

Muitas equipes usam pontos de história como uma maneira de representar o esforço e a complexidade na estimativa. Um ponto baixo da história indica uma história de baixa complexidade e baixo esforço, enquanto os pontos altos da história indicam complexidade e esforço em toda a equipe. Muitas equipes atribuem pontos com base na sequência de Fibonacci, de modo que maior complexidade e maior esforço refletem um aumento exponencial nos pontos da história.

Além disso, as melhores equipes colocam alguma linguagem de qualificação em torno de tarefas pontuais. Por exemplo, uma equipe pode qualificar uma história de três pontos para pequenas alterações ou adições à experiência do usuário que não exigem alterações de back-end ou de API. Você pode ver que essa qualificação limita o esforço a provavelmente um desenvolvedor de front-end e baixo risco, porque as alterações estão sendo implementadas apenas na camada da web.  

Como usar
Geralmente, as equipes levam vários sprints para normalizar suas práticas de estimativa. Mas uma vez definidas, existem várias maneiras importantes de usá-las. 

As equipes devem começar por otimizar seus processos de comprometimento e desenvolvimento, compreendendo sua velocidade e quais misturas de histórias podem gerir. As equipes devem entender melhor quantas histórias pequenas, médias e grandes podem ser executadas de maneira ideal. Muitas equipes reconhecem o risco e a coordenação necessárias para completar histórias maiores, de modo que se comprometem com poucas histórias grandes e muitas pequenas em um sprint.

Os gráficos de burndown que estão disponíveis na maioria das ferramentas de gerenciamento ágil agora podem ser ponderados pelas estimativas e usados ​​para otimizar o trabalho durante o sprint. Além disso, as burrowns épicas e de lançamento agora têm mais significado, pois ajudam as equipes a se concentrarem em histórias de maior valor e risco no início do processo de desenvolvimento.

Para equipes com pipelines automatizadas e releases mais frequentes, as histórias estimadas se tornam uma ferramenta valiosa para decidir como gerenciar o pipeline de desenvolvimento. Recursos de execução mais longa podem ser melhor gerenciados em ramificações de recursos; os médios, com sinalizadores de recursos; e alterações menores, diretamente no ramo de desenvolvimento mestre.

Por último, as equipes podem começar a medir a magnitude de sua dívida técnica. Quando a dívida é identificada e capturada no backlog, uma estimativa deve ser atribuída ao esforço e à complexidade para resolvê-la. Quando as equipes adicionam histórias técnicas de dívida ao seu backlog e estimam proativamente, passam a ter uma medida da dívida técnica total. Eles também podem relatar quanto de técnica será priorizada e abordada em cada sprint e/ou release. 

Usando estimativas para orientar a priorização
Depois que as equipes desenvolverem confiança em suas estimativas, elas poderão ser usadas com proprietários de produtos e líderes de negócios. O ponto de partida é desenvolver um processo de planejamento que tenha como objetivo obter o priorizado e o estimado para cada história. Algumas organizações realizam planejamento ágil em paralelo aos seus esforços de desenvolvimento, enquanto outras desenvolvem um ciclo de sprint separado para o planejamento . No livro Driving Digital compartilho um processo de dois estágios para a escrita de histórias onde os “stubs da história” são esboçados e estimados no estágio um e os stubs priorizados são então totalmente escritos e reestimados como histórias no estágio dois.

Quando um recurso é estimado, a equipe pode ter uma discussão mais orientada por dados com o proprietário do produto sobre escopo e prioridade. Por exemplo: a Matéria A com cinco histórias e 35 pontos é mais importante que a Matéria B com duas histórias e 12 pontos? Ou talvez, se os requisitos para o Recurso A forem simplificados, isso pode levar a uma estimativa reduzida. 

Quando as equipes estimam vários recursos em seu backlog, isso também pode levar a um melhor planejamento de liberações e ao desenvolvimento de roteiros com o proprietário do produto. As equipes podem analisar o tipo de trabalho e os tamanhos das histórias e apresentar opções sobre quais recursos podem ser trabalhados de maneira ideal para uma próxima versão.

O que não  deve ser feito com estimativas ágeis
Existem vários ocasiões em que o uso de estimativas é problemático. A primeira é quando as organizações aplicam o acompanhamento de tempos e desejam comparar as horas reais aplicadas a uma história em comparação com a estimativa. Essa comparação não funciona bem ao estimar com pontos de história, porque os pontos geralmente representam complexidade e esforço. Mesmo quando estimamos em horas, é melhor que as equipes avaliem sua entrega sobre compromissos e capacidade de manter ou aumentar a velocidade, em vez de examinar as estimativas individuais.

Em segundo lugar, quando os gerentes tentam fazer alocação de recursos usando as estimativas. Eles podem sugerir que uma pessoa na equipe pode fazer mais trabalhos porque atribuiu menos pontos que nos sprints anteriores. Essa lógica é profundamente falha, porque as equipes ágeis não levam em conta a participação de todos os membros da equipe na conclusão de histórias de usuários. Essa forma de gerenciamento de recursos equivale à microgestão, mas isso bloqueia o sucesso das equipes ágeis, que são baseadas em equipes confiáveis ​​para assumir compromissos honestos.

Uma questão semelhante ocorre quando os gerentes tentam usar atribuições e estimativas para avaliar o desempenho individual. Mais uma vez, as equipes de estimativas e atribuições ao gerenciar suas prioridades não são a melhor ferramenta para revisar a produtividade individual.