Gerando métricas ágeis a partir de informações do Jira

A CWI vem incentivando fortemente o uso de métricas ágeis em seus projetos e elas estão permeando cada vez mais a cultura da empresa. Primeiramente é importante deixar claro que as métricas ágeis não são ou não devem ser utilizadas para controle e microgerenciamento, mas sim visando a previsibilidade, visibilidade, identificação de gargalos e oportunidades de melhorias em seus projetos e times.

Pensando nisso, a CWI selecionou um conjunto de métricas recomendadas, das quais falaremos nesse artigo. Elas foram extraídas com informações do Jira Server (uma solução auto gerenciada da ferramenta) e o framework utilizado é o Scrum.

Todas elas são geradas diretamente no Jira ou no Excel a partir de dados exportados pela ferramenta. A integração direta do Excel com o Jira não está disponível para o Jira Server.

As métricas abaixo fazem parte de um conjunto sugerido pela CWI, mas que são justificadas a partir da necessidade de se tomar uma decisão. No cenário em que foram utilizadas, os objetivos eram acompanhar a assertividade das estimativas, melhoria de qualidade e produtividade. São elas:

• Previsto x Realizado;
• Quantidade de defeitos em homologação;
• Quantidade de defeitos em produção;
• Taxa de entrega de atividades por período (Througput);
• CFD.

---

Configuração do Jira

A configuração do Jira pode variar de acordo com a necessidade do processo. Não existe uma “receita de bolo” e é importante ter isso em mente. A configuração a seguir foi utilizada em um cliente, no entanto, para que as informações geradas estejam corretas, alguns pontos devem ser considerados:

• Unidade de medida — Considerada estimativa de esforço em horas para todas as Issue Types;

• Throughput — As issues somente são consideradas como entregues, após atenderem os itens previstos no DoD (O que é “Definition of Done” DOD), dessa forma transitam para a etapa final do fluxo “Done”. Esta etapa agrupa itens em ambos status “Teste M3” e “Done” para o fluxo de valor do cliente. Itens entregues em homologação (Test M3) já podem ser considerados concluídos e contabilizados no throughput, bem como itens parcialmente construídos não contabilizam;

• Planejamento — Ao planejar uma atividade é considerado a estimativa total do item, mesmo que já iniciado na Sprint anterior, dessa forma é possível garantir que somente itens concluídos sejam considerados no throughput, contabilizando somente na Sprint em que foram finalizados.

Na imagem acima, apesar da estimativa estar configurada para contabilizar a partir do tempo original estimado, também foi habilitado o Time Tracking baseado no tempo restante. Isso habilita um burndown adicional que é sensibilizado conforme o time vai evoluindo na(s) atividade(s), mas isso pode ser material para outro artigo.

Workflow

Apesar de estarmos utilizando o Scrum, o workflow completo emprega o conceito de upstream e downstream oriundo do Kanban para a representação do seu lead time, porém, neste artigo iremos focar somente no downstream para a extração das métricas.

Abaixo o fluxo de trabalho completo:

Board Downstream

Conforme citado acima, a parte do fluxo que as métricas são extraídas é visível em “Downstream Cycle Time”, o mesmo pode ser visto mais detalhadamente em “Sprint Backlog”, onde é demonstrado o fluxo por tipo de item. De acordo com o detalhamento acima, considere:

• Story: principal issue type do workflow, representa entregas de valor para o negócio e considera fortemente o conceito de INVEST (Como escrever as melhores User Stories com INVEST), passa integralmente por todas as etapas do fluxo e é liberado pelo PO, responsável pela homologação;

• Task: issue type criada para itens que não trazem diretamente valor para o negócio, nesse caso os itens são liberados diretamente em homologação (Test M3);

• Bug Versão: bugs abertos e fechados dentro da própria Sprint;

• Bug HML: bugs identificados no ambiente de homologação, originados a partir de uma Story ou Task já consideradas entregues ao cliente. Estes são estimados e incluídos no Sprint Backlog.

Jira Query Language (JQL)

A forma mais eficaz de extrair informações do Jira é a partir de uma JQL, portanto para cada métrica é necessário uma ou mais JQL’s. Existem também plugins para o Excel e Google Sheets que integram diretamente com o Jira.

---

Previsto x Realizado

Visando demonstrar a eficiência em estimativas e entregas, esta métrica baseia-se em comparar duas séries de dados: estimativas originais (original estimate) e tempo gasto (time spent). Para o cálculo de estimativas originais considera-se somente o próprio item, porém, para o cálculo de tempo gasto é necessário computar todos os bugs gerados, pois eles fazem parte do esforço desprendido para a conclusão do item.

Abaixo, uma visão agrupada por sprints, mostrando a evolução de 2020 a 2022:

Outras visões também podem ser facilmente geradas utilizando o mesmo conjunto de informações de origem, ex.: mensalmente, por componente e por épico.

---

Quantidade de defeitos por ambiente

Gerado em visões de quantidade e esforço, é possível configurar de acordo com o ano, ambiente e período desejado. Este gráfico já satisfaz duas métricas técnicas citadas na introdução, “Quantidade de defeitos em homologação” e “Quantidade de defeitos em produção”, além de também exibir defeitos encontrados durante a etapa de desenvolvimento.

---

Taxa de entrega de atividades por período (Througput)

O Througput tem o objetivo de demonstrar o rendimento a partir do número de itens concluídos por unidade de tempo. No gráfico abaixo, foi gerada uma visão da taxa mensal, dos anos de 2020, 2021 e 2022 (parcial). Essa visão pode ter o período ajustado para uma melhor visualização.

Diagrama de Fluxo cumulativo (CFD)

O CFD (cumulative flow diagram) é gerado pelo próprio Jira e nesta visão está considerando o fluxo completo, upstream e downstream, compreendendo o período que os itens integram o backlog do produto até sua liberação em produção.

Além de possibilitar identificação de riscos e impedimentos, o CFD também fornece outros indicadores, como throughput, cycle time, lead time e work in progress.

---

Conclusão

As métricas no Jira podem ser facilmente exibidas em diversas visões e de acordo com a necessidade. Já para as métricas que precisam ser geradas externamente, basta salvar a JQL utilizada para a geração do relatório e este pode ser exportado em forma de arquivo sempre que se desejar métricas atualizadas. No caso do Jira Cloud, o Excel pode ler diretamente a JQL.

A geração e análise das métricas no projeto em questão possibilitou identificar algumas deficiências e trabalhar determinadas ações, onde por meio da melhoria contínua se obteve um significativo aumento da maturidade do time, resultando em melhor assertividade das estimativas e aumento de qualidade e produtividade nas entregas.

No próximo artigo, será demonstrado como integrar o Excel diretamente com o Jira Cloud.

Gostou deste conteúdo? Me procure e vamos conversar sobre outras métricas que podem ser geradas diretamente pelo Jira.