Cinco métricas ágeis de KPI que você não vai odiar
As estatísticas e gráficos são ferramentas poderosas. Os agilistas devem sempre usar esses recursos… sempre!
Obtenha o template grátis de relatórios de projetos
Obtenha uma visão geral completa dos projetos com relatórios otimizados, consistentes e abrangentes.
Métricas são um assunto delicado.
Por um lado, todo mundo já participou de um projeto em que nenhum tipo de dado era monitorado, e era difícil dizer se o cronograma estava em dia para o lançamento ou melhorando com o tempo. Por outro, muitos já tiveram a infelicidade de trabalhar em um projeto em que as estatísticas eram usadas como arma, colocando uma equipe contra a outra ou justificando o trabalho em fins de semana. Então não é surpresa que a maioria das equipes tenha uma relação de amor e ódio com as métricas.
Mas não precisa ser assim. Acompanhar e compartilhar métricas ágeis pode diminuir a confusão e mostrar o progresso da equipe (e retrocessos) durante todo o ciclo de desenvolvimento. Veja como.
Conheça o seu próprio negócio
"Concluído" conta apenas metade da história. É criar o produto certo, no momento certo, para o mercado certo. Ficar em dia durante todo o programa é coletar e analisar dados relevantes ao longo do processo. Em qualquer programa ágil, é importante monitorar as métricas de negócios e as métricas de times ágeis. As métricas de negócios têm como foco observar se a solução está atendendo as necessidades do mercado, e as métricas de times ágeis mensuram os aspectos do processo de desenvolvimento.
As métricas de negócio de um programa devem estar enraizadas no seu roteiro.
Para cada iniciativa no roteiro, inclua vários indicadores-chave de desempenho (KPIs) associados às metas do programa. Além disso, inclua os critérios de sucesso para cada requisito do produto, como a taxa de adoção dos usuários finais e a porcentagem de código coberta pelos testes automatizados. Esses critérios de sucesso alimentam as métricas ágeis do programa. E quanto mais as equipes aprendem, mais capacidade de adaptação e evolução elas garantem.
Como usar métricas ágeis de KPI para otimizar a entrega
Gráfico de burndown do sprint
Equipes scrum organizam o desenvolvimento em sprints com intervalos de tempo. Desde o início do sprint, a equipe prevê quanto trabalho pode fazer durante um sprint. O relatório de burndown então monitora a conclusão do trabalho durante todo o sprint. O eixo x representa o tempo e o eixo y refere-se à quantidade de trabalho ainda não concluída, medida em pontos de história ou horas. O objetivo é ter todo o trabalho previsto concluído até o final do sprint.
Uma equipe que demonstra consistência no cumprimento das previsões é uma propaganda convincente para a agilidade em sua organização. Mas não caia na tentação de contornar os números declarando um item como completo antes que esteja mesmo. Pode parecer bom no curto prazo, mas, a longo prazo, essa abordagem só dificulta a aprendizagem e a melhoria.
Antipadrões que devem ser observados
A equipe finaliza mais cedo do que o esperado, sprint após sprint, porque está se comprometendo a fazer menos do que poderia.
A equipe perde a previsão, sprint após sprint, porque está se comprometendo a fazer mais do que poderia.
A linha de burndown mostra quedas bruscas em vez de um burndown mais gradual porque o trabalho não foi dividido em partes menores.
O proprietário do produto adiciona ou altera o sprint intermediário do escopo.
Burndown da versão e do epic
Os gráficos de burndown de epic e liberação (ou versão) monitoram o progresso de desenvolvimento de uma grande parte do trabalho do que em relação ao burndown de sprint, e orientam o desenvolvimento de equipes scrum e kanban. Como um sprint (para equipes scrum) pode conter trabalho de vários epics e versões, é importante monitorar o progresso de sprints individuais, bem como epics e versões, para visualizar as métricas kanban.
O “desvio de escopo” é a inserção de mais requisitos em um projeto já definido. Por exemplo, se a equipe está trabalhando em um novo site para a empresa, o desvio de escopo pode ser a solicitação de novas funções após a finalização dos requisitos iniciais. Embora não seja bom tolerar o desvio de escopo durante um sprint, a alteração do escopo nos epics e versões é uma consequência natural do desenvolvimento ágil. À medida que a equipe avança pelo projeto, o proprietário do produto pode decidir se assume ou elimina o trabalho com base no que estão aprendendo. Com os gráficos de burndown de epic e lançamento, todos ficam por dentro do que acontece no fluxo de trabalho dentro do epic e da versão.
Antipadrões que devem ser observados
Previsões de liberação ou epic não são atualizadas à medida que a equipe trabalha.
Nenhum progresso é feito ao longo de várias iterações.
O deslizamento de escopo crônico, que pode ser um sinal de que o proprietário do produto não entende completamente o problema que a parte do trabalho está tentando resolver.
O escopo cresce mais rapidamente do que a equipe pode absorvê-lo.
A equipe não está enviando liberações adicionais durante o desenvolvimento de um epic.
Velocidade
Velocidade é a quantidade média de trabalho que uma equipe de scrum conclui durante um sprint, medida em horas ou pontos de história, e é muito útil para previsão. O proprietário do produto pode usar velocidade para prever o quão rapidamente uma equipe pode trabalhar em uma lista de pendências, porque o relatório rastreia o trabalho previsto e o concluído ao longo de várias iterações – quanto mais iterações, mais precisa a previsão.
Digamos que o proprietário do produto quer concluir 500 pontos de história na lista de pendências. Sabemos que a equipe de desenvolvimento geralmente conclui 50 pontos de história por iteração. O proprietário do produto pode assumir, razoavelmente, que a equipe precisará de dez iterações (mais ou menos) para concluir o trabalho necessário.
É importante monitorar como a velocidade evolui ao longo do tempo. Novas equipes podem esperar ver um aumento na velocidade à medida que as relações e o processo de trabalho são otimizados. Equipes existentes podem monitorar sua velocidade para garantir um desempenho consistente ao longo do tempo e podem confirmar se uma mudança de processo específica fez melhorias ou não. Uma diminuição na velocidade média é geralmente um sinal de que alguma parte do processo de desenvolvimento da equipe tornou-se ineficiente e deve ser avaliada na próxima retrospectiva.
Antipadrões que devem ser observados
Quando a velocidade for errática durante um longo período, sempre reveja as práticas de estimativa da equipe. Durante a retrospectiva da equipe, faça as perguntas seguintes:
Há desafios imprevistos de desenvolvimento com os quais não contávamos ao estimar este trabalho? Como podemos dividir melhor o trabalho para descobrir alguns desses desafios?
Há alguma pressão de negócios levando a equipe para além de seus limites? Há uma piora na adesão às melhores práticas de desenvolvimento em decorrência disso?
Como uma equipe, estamos sendo cuidadosos demais na estimativa do sprint?
A velocidade de cada equipe é única. Se a equipe A tiver uma velocidade de 50 e a equipe B tiver uma velocidade de 75, isso não significa que a equipe B tenha maior produtividade. Uma vez que a cultura de estimativa de cada equipe é única, sua velocidade também vai ser. Resista à tentação de comparar a velocidade entre equipes. Meça o nível de esforço e os resultados do trabalho com base na interpretação única que cada equipe faz dos pontos da história.
Gráfico de controle
Os gráficos de controle trazem o tempo de ciclo de itens individuais, o tempo total de “em andamento” para “concluído”. É provável que as equipes com tempos de ciclo mais curtos tenham produtividade maior, e as equipes com tempos de ciclo consistentes por muitos itens são mais previsíveis na entrega de trabalho. Embora o tempo de ciclo seja uma métrica primária para equipes de Kanban, as equipes de Scrum também podem se beneficiar do tempo de ciclo otimizado.
Medir o tempo de ciclo é um modo eficiente e flexível de melhorar os processos de uma equipe, pois os resultados das mudanças são perceptíveis quase imediatamente, permitindo que a equipe faça quaisquer ajustes necessários. A meta final é ter um tempo de ciclo curto e consistente, independentemente do tipo de trabalho (novo recurso, débito técnico, etc.).
Antipadrões que devem ser observados
Os gráficos de controle podem parecer instáveis no início. Não fique tão preocupado com todos os valores atípicos. Procure por tendências. Aqui estão duas áreas para observar:
Aumentar o tempo de ciclo - aumentar o tempo de ciclo diminui a agilidade que a equipe trabalhou muito para obter. Na retrospectiva da equipe, reserve um tempo para entender um aumento desse tipo. Uma exceção: se a definição da equipe de "concluído" tiver sido expandida, o tempo de ciclo provavelmente também vai ser expandido.
Tempo de ciclo irregular: a meta é implementar um tempo de ciclo consistente para os itens de trabalho que têm valores de ponto da história parecidos. Filtre o gráfico de controle em cada valor de ponto da história para verificar a consistência. Se o tempo de ciclo for irregular em valores de ponto de história pequenos e grandes, passe um tempo na retrospectiva examinando as falhas e melhorando as estimativas futuras.
Diagrama de fluxo cumulativo
O diagrama de fluxo cumulativo deve parecer mais suave da esquerda para a direita. Bolhas ou lacunas de uma cor indicam carências e obstáculos, então, quando vir uma, procure por modos de suavizar a faixa de cor no gráfico.
Antipadrões que devem ser observados
Problemas de bloqueio criam backups grandes em algumas partes do processo e ausências em outros.
Crescimento do backlog não verificado ao longo do tempo. Isso acontece quando os proprietários do produto não encerram os itens que estão obsoletos ou que têm prioridade muito baixa para serem abordados.
Mais métricas ainda
Boas métricas não são limitadas aos relatórios discutidos acima. Por exemplo, a qualidade é uma métrica importante para as equipes ágeis e há um número de métricas tradicionais e métricas kanban que podem ser aplicadas ao desenvolvimento ágil:
Quantos defeitos são encontrados?
durante o desenvolvimento?
após a liberação para os clientes?
por pessoas fora da equipe?
Quantos defeitos são adiados para uma liberação futura?
Quantos pedidos de suporte ao cliente estão chegando?
Qual é a porcentagem de cobertura de teste automatizado?
As equipes ágeis também devem analisar a velocidade de de entrega e a frequência da liberação. No final de cada sprint, a equipe deve liberar o software para produção. Com que frequência isso realmente acontece? A maioria das liberações está sendo enviada? Na mesma linha, quanto tempo leva para a equipe liberar uma correção de emergência para produção? A liberação é fácil para a equipe ou exige muito trabalho?
Encontre dados contextualizados
O Insight é uma excelente ferramenta para as equipes acessarem métricas ágeis quando for necessário: durante o planejamento de sprints, em verificações nas reuniões rápidas diárias ou na otimização de entregas. Você pode encontrar dados no canto superior direito da visualização de quadro, backlog e implementações do Jira.
O Insight oferece imagens instantâneas das seguintes métricas ágeis e kanban:
Progresso do sprint
Detalhamento do tipo de item
Compromisso de sprint
Frequência de implementação
Tempo de ciclo
Use estas métricas e indicadores ágeis para otimizar sem interrupções o desempenho da equipe. Saiba mais sobre o Insight.
Conclusão...
As métricas ágeis e os KPIs são apenas uma parte da criação da cultura da equipe. Eles proporcionam insights quantitativos sobre o desempenho da equipe e oferecem metas mensuráveis para ela. Essas métricas são importantes, mas não precisa se preocupar tanto com elas. Ouvir o feedback da equipe durante as retrospectivas é tão importante quanto elas para aumentar a confiança da equipe, a qualidade do produto e a velocidade de desenvolvimento no processo de lançamento. Use os feedbacks quantitativos e qualitativos para impulsionar a mudança.
Recommended for you
Templates
Templates prontos do Jira
Confira nossa biblioteca de templates personalizados do Jira para várias equipes, departamentos e fluxos de trabalho.
Guia do produto
Uma introdução completa ao Jira
Use este guia detalhado para descobrir as principais funções e as melhores práticas para maximizar sua produtividade.
Guia do Git
Como entender o básico do Git
De iniciantes a especialistas avançados, use este guia para aprender o básico do Git com dicas e tutoriais úteis.