Conheça 5 métricas para gestão ágil de projetos

gestão ágil de projetos
7 minutos para ler

Na gestão ágil de projetos, métricas e indicadores são fundamentais para uma visão clara da performance e do engajamento dos times. Sem medir, somos incapazes de comparar os resultados futuros com os atuais, não sendo possível saber se estamos de fato melhorando ou apenas mudando por mudar.

Muitas métricas e KPIs que já existem em uma empresa com cultura Data-Driven podem ser adaptados para o contexto do Agile, mas, neste artigo, selecionamos 5 métricas para a gestão ágil de projetos. Confira!

[E-BOOK] Governança de dados: como utilizar e implementar com metodologias ágeis

1. Sprint Burndown

O Sprint Burndown é amplamente aplicado em squads que utilizam o Scrum em todo o mundo. O Burndown é um gráfico de linhas que começa com a soma de todas as tarefas planejadas para uma iteração, ou sprint. Todos os dias, os times atualizam esse gráfico com o que foi executado, o que faz com que a linha a cada dia se aproxime mais do 0 no eixo horizontal.

Quando a linha finalmente chega lá, em teoria todo o trabalho planejado está finalizado. Se isso acontecer no fim da interação, o planejamento foi ideal. Se acontece antes ou não acontece, pode ser interessante ajustar expectativas.

Existem algumas formas de construir o gráfico do Sprint Burndown. Se o time utiliza algum sistema de pontuação ou precificação de tarefas, o valor total normalmente será a soma desses pontos. Outras equipes preferem apenas somar a quantidade bruta de tarefas. Considerar o tempo estimado em horas e minutos das tarefas no gráfico não é recomendado.

Como cada equipe normalmente tem um tipo diferente de pontuação de tarefas, ainda que usem um mesmo sistema, o gráfico de Burndown não é uma ferramenta útil para comparar a performance de times diferentes, mas pode ser interessante para comparar uma mesma equipe em momentos distintos.

Isso quer dizer que podemos pegar o Burndown de algumas sprints para trás e comparar com um mais recente para avaliar os efeitos de uma mudança de horário de trabalho, adição de um novo membro na equipe e outros ajustes gerenciais.

Além de estar no grupo das métricas de avaliação, o Burndown também é uma métrica de transparência no decorrer de uma sprint. Com as atualizações diárias, é possível verificar se o ritmo de execução está otimizado e acompanhar de forma visual a realização do trabalho, o que é também motivador para todos.

2. Tempo de bloqueio por história

Para que o time entregue o máximo de performance ao longo de cada sprint, precisamos garantir que cada pessoa tenha plenas condições de executar o seu trabalho o tempo todo, ou seja, que não esteja “bloqueada” por qualquer razão que seja.

No Scrum, o responsável por “abrir caminho” entre os obstáculos que a equipe enfrenta é o Scrum Master. Todos os dias, na reunião diária, o Scrum Master conversa com os membros do time para detectar empecilhos que possam prejudicar suas entregas e depois trabalha para tirar esses bloqueios do caminho.

O tempo de bloqueio por história é o período que cada obstáculo leva para para ser removido. Um tempo o mais baixo possível é ideal, mas caso o valor da métrica seja alto, muito provavelmente a organização não proporciona autonomia para que o Scrum Master trabalhe na remoção de obstáculos, o que é comum em estruturas organizacionais mais antigas.

3. Métricas de saúde, engajamento e felicidade do time

O cofundador do Scrum, Jeff Sutherland, sugere que uma métrica de “felicidade” pode ser importante para garantir o engajamento dos times e, com isso, uma performance superior no trabalho. Outros especialistas preferem criar métricas de “saúde” das equipes. No geral, o importante não é o nome dado a esse tipo de métrica, mas sim a sua existência e acompanhamento.

Cultura data-driven

Em todo framework ágil existem mecanismos de melhoria contínua, como a Retrospectiva do Scrum. A ideia desse tipo de ferramenta é assegurar que tanto o processo como as pessoas envolvidas estejam em evolução sempre, encontrando formas melhores de entregar valor e otimizar o trabalho.

Mas, para que a melhoria contínua seja possível, é importante que exista o envolvimento do time. Qualquer alteração de humor ou disposição pode se tornar um problema maior se não foi detectado precocemente e ajustado. Para dar visão ao Scrum Master ou qualquer que seja o profissional guardião dos processos e pessoas, é interessante elaborar uma métrica de felicidade ou saúde do time.

Uma sugestão é adaptar uma versão do conhecido NPS (Net Promoter Score). Crie entre 4 e 6 perguntas como “Você acredita que o time está entrosado?” ou “Você confia nas decisões do Product Owner?” e peça que cada um responda com notas entre 1 e 10. Dependendo do tipo de pergunta, pode ser interessante permitir que as respostas sejam anônimas, para que ninguém tenha medo de represálias.

4. Falhas por Release

Especialmente na área de software, é comum que cada entrega seja acompanhada por um número de bugs ou falhas de qualquer tipo, incluindo aqueles que não cumprem com todos padrões de qualidade estabelecidos.

Mas, diferentemente do trabalho rotineiro de uma fábrica, em que existem etapas de qualidade que filtram os produtos que não atendem a requisitos de aceitação, em um projeto as falhas são ainda mais perigosas e podem comprometer significativamente o produto como um todo. Por isso, é muito importante mensurar e acompanhar erros de forma consistente.

A métrica de Falhas por Release é tão simples como o nome sugere: contar quantas falhas foram detectadas em um Release disponibilizado pelo time. Um Release pode ser o resultado de uma única sprint, ou, mais usualmente, uma combinação de mais de uma delas.

5. Lead Time

A gestão ágil de projetos é sempre orientada pela geração de valor. Mais do que entregar com velocidade, o objetivo aqui é que a cada iteração ou incremento do projeto o máximo de valor seja entregue.

Mas é natural que em muitas empresas seja desejável medir a velocidade de entrega dos times, especialmente quando utilizamos um framework ágil não exatamente para um projeto futuro, mas para incrementos em sistemas e processos que já estão rodando e fazem parte do cotidiano dos clientes.

Em linhas gerais, o Lead Time pode ser definido como o tempo que leva a entrega de algo a partir do momento em que o time se compromete com a demanda. Quando um colaborador liga para o setor de TI e pede uma reposição da sua estação de trabalho, o Lead Time é calculado como todo o tempo até que o solicitante tenha sua nova máquina em mãos.

Mais do que trabalhar com estimativas, é interessante medir o Lead Time para conhecer o tempo de resposta dos times de projetos e saber como seria possível diminui-lo.

Na gestão ágil de projetos, essas métricas podem ser muito importantes. Afinal, ao utilizar dados para enxergar melhor, os tomadores de decisão da empresa podem fazer escolhas mais acertadas. E, como já foi dito, não é preciso se limitar a essas 5: muitas outras métricas também podem ser aplicadas no ambiente ágil.

Gostou de aprender essas 5 métricas para gestão ágil? Aproveite o embalo e compartilhe com seus amigos no Facebook, LinkedIn, Youtube e Instagram!

Você também pode gostar

Deixe um comentário