Métricas que todo Scrum Master deveria estar olhando

Sempre costumo dizer em meus treinamentos que “ágil não é bagunça”. A prova disso é a disciplina necessária para conseguir pôr em prática as 19 páginas do Scrum Guide, fora a quantidade de estudo que demanda as técnicas complementares como User Stories, Pair Programming, Kanban, Planning Poker e muito mais. Mas algo pouco debatido e muitíssimo importante é a parte de métricas ágeis do time.

Mas porque eu preciso de métricas em times ágeis?

Para que exista um plano de melhoria contínua concreto em execução junto ao time.

Sem métricas o time simplesmente pode rodar o ágil na sua forma mais básica, mas não estará melhorando continuamente o que é um grande risco. Estudiosos dos processos japoneses de manufatura, de onde o Lean surgiu (Toyota) e de onde o Scrum foi baseado, são categóricos em afirmar que todo processo enxuto de produção (logo os processos ágeis também) sofrem deterioração ao longo do tempo se não estão sempre em contínuo esforço de melhoria. Ou seja, ser ágil é uma jornada, não um destino.

Logo, se para me manter ágil devo sempre estar buscando a melhoria contínua e para que possa melhorar continuamente de maneira sustentável e assertiva, preciso de métricas. Isso fica ainda mais evidente quando você como Scrum Master full-time ou Agile Coach (meu caso) deve estar olhando para mais de um time ao mesmo tempo, mas não subestime o poder de ter métricas sob constante vigilância mesmo em times pequenos e avulsos.

Velocidade (Velocity)

Essa é a métrica mais básica que todo Scrum Master tem de mensurar. Qual a capacidade de entrega do seu time?

Não importa qual a unidade de medida que você utilizar: número de cards, Story Points, T-Shirt Size (número de itens P, M ou G que o time entrega por Sprint) ou horas. Você tem de conhecer o passo do seu time para que seja possível fazer ajustes quando há variação pra menos ou quando se quer acelerar o time. Além disso, ter a métrica de velocidade auxilia na previsibilidade do roadmap do Product Owner, obviamente sempre respeitando o bom senso e a máxima de que “a única constante em software é a mudança”.

Como medir a velocidade do time? Os métodos ágeis são empíricos, logo, baseiam-se em experiência prática passada para poder tirar conclusões sobre o futuro próximo. Sendo assim, o único jeito de saber a velocidade do time é fazendo com que ele rode de uma a três sprints, de preferência com a mesma formação, para ter uma média e poder descobrir essa métrica.

Muito importante ressaltar que a velocidade de um time é reflexo de todo um contexto que envolve: tecnologia, perfis de pessoas, experiência do time, quanto tempo trabalham juntos, o quanto conhecem do projeto, etc. Qualquer alteração nesse sensível contexto irá provocar oscilações na velocidade.

Mais importante ainda é ressaltar que jamais você deve comparar a velocidade de dois times. Medimos a velocidade de um time para compará-lo sempre com ele mesmo, jamais com os outros.

Na ferramenta Visual Studio Online (TFS) a velocidade (Velocity) é calculada automaticamente no Product Backlog, desde que você use o campo Effort dos Product Backlog Items/User Stories (dependendo do seu template) corretamente. Você encontra esta informação no canto superior direito da tela, na visão de Product Backlog. Também é possível adicionar um widget Velocity no dashboard do time.

Velocity
Velocity

Tempo por Lead e Tempo por Ciclo (Lead Time e Cycle Time)

Lead time na área de supply chain é o tempo total de um pedido ser feito por um cliente até o mesmo ser entregue a ele e a ideia aqui não é diferente. É uma métrica que geralmente está associada ao uso do Kanban e dá um pouco mais de trabalho para ser medida dependendo das ferramentas que você tem à disposição. Basicamente o Lead Time é o tempo que leva de uma tarefa que foi criada no backlog até ela chegar no estado DONE ou seja, o tempo total de vida de um item de backlog (não necessariamente de desenvolvimento).

Já o Cycle Time é o tempo de desenvolvimento de uma atividade, ou seja, desde quando ela entrou em DOING/In Progress, até ela chegar em DONE, sendo sempre menor ou igual ao Lead Time.

Ambas métricas vão te dar um número de horas ou dias para finalizar cada atividade, sendo que para o cliente, o que importa é o Lead Time (total, desde o pedido).

Times ágeis devem buscar quebrar seus itens de backlog em pedaços executáveis dentro de um espaço de tempo razoável. Obviamente razoável varia de time para time, mas algumas boas práticas recomendam que o lead time de uma história não seja maior do que uma sprint. Também podemos incluir nas boas práticas que o lead time de uma tarefa (lembrando que uma história pode desmembrar em várias tarefas) não deveria levar mais do que um ou dois dias.

Assim, cravando alguns objetivos desejáveis ou apenas medindo o histórico vs situação atual, podemos analisar itens que possuam variações grosseiras de lead time e de cycle time e ajustar onde que está o problema no seu pipeline de desenvolvimento. Esse processo de melhoria contínua do Lead/Cycle Time é tema do famoso Improvement Kata da Toyota (onde o Cycle Time é chamado de Takt Time), onde objetivando chegar em uma visão ideal, partimos de uma condição atual para condições-alvo mais próximas rumo ao objetivo, aplicando PDCA a cada ciclo para melhoria.

No Visual Studio Online é possível ver todo o ciclo de vida de uma tarefa indo na aba History dela, como no exemplo abaixo.

Task History
Task History

Analisando o tempo entre a troca de estados da tarefa é possível perceber que o gargalo dela foi no Code Review, que demorou 15 dias para acontecer, contra apenas 2 dias de desenvolvimento e 2 de espera para entrar em desenvolvimento. Assim, temos um Lead Time de 17 dias e um Cycle Time de 16 dias. É óbvio o problema aqui e onde devemos colocar nosso esforços, muito diferente do que apenas tentar melhorar a velocidade de codificação do programador, quando não é nisso que reside o problema.

Obviamente que analisar tarefa por tarefa não é uma tarefa muito ágil e por isso é recomendada a instalação da extensão de Analytics no Visual Studio Online, para ter à disposição aos widgets de Lead Time e Cycle Time que podem lhe ajudar muito nos seus dashboards. Apenas analise individualmente as atividades que tenham fugido grosseiramente do Lead/Cycle Time e que possam ser a razão de suas sprints não estarem rolando tão bem.

Lead Time
Lead Time

Como o Lead Time não é tão bem rastreado pelos times quanto o Cycle Time (que é bem representado nas colunas do Kanban), recomenda-se para tarefas cujo lead time não tenha sido satisfatório o desenho do processo de pré-jogo (antes de entrar pra sprint) com as estimativas de tempo em cada etapa para entender onde está o gargalo. É bem comum os times se focarem em otimizar o cycle time quando muitas vezes o gargalo é antes disso, em processos de análise, especificação, etc.

O desenho abaixo que mostra um processo de pedido de software até a sua entrega na nuvem mostra como muitas vezes o maior tempo é o de espera entre cada uma das etapas do desenvolvimento, em especial (mas não somente) como acontece no modelo waterfall.

Processo de Exemplo
Processo de Exemplo

Neste processo, enquanto que o desenvolvimento levou 3h, o teste 30min e o deploy 4h, o Lead Time da demanda custou um mês de espera pra empresa. O que você faria neste caso, pediria para os desenvolvedores programarem mais rápido? Você investiria pesado em um sistema de deploy automatizado?

Outras métricas

Algumas literaturas consideram o Burndown Chart como uma métrica também,  assim como Burnup, embora eu não irei incluir aqui para não chover no molhado. Você também pode querer medir a quantidade de incidentes que entram por sprint e agrupar as razões do mesmo, para fazer uma sustentação adequada e assertiva no seu time (chega de paliativos!).

Dependendo do background do Scrum Master, outras métricas podem ser incluídas como Test Coverage e Bugs por Sprint. Se o time for responsável por manter a operação do produto que desenvolvem, métricas de disponibilidade como Uptime/Downtime podem ser adicionadas, mas sinceramente eu não acredito que tais métricas sejam responsabilidade do Scrum Master, mas sim do Time de Desenvolvimento, a menos que o Scrum Master também vista o chapéu de líder técnico do time, o que já fiz muito no passado.

Algumas dessas métricas são facilmente coletadas e apresentadas em dashboards caso você use o Visual Studio Online, seja com os widgets ou com as queries. Caso você seja mais oldschool e use quadros físicos, a coleta e apresentação terá de ser manual, o que pode desmotivar um pouco a prática constante. Nestes casos eu recomendaria uma apuração mais sazonal, principalmente quando as retrospectivas mostram que algo poderia estar indo melhor na produtividade do time.

E você, quais métricas usa em seus times ágeis?

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

O que achou desse artigo?
[Total: 1 Média: 5]