Guia Scrum | 11. Estatísticas e métricas que o Scrum Master deve acompanhar

Por que o Scrum Master precisa de estatísticas e métricas? Primeiro, verificar se seus métodos de trabalhar a previsibilidade de resultados e melhorar a eficácia da equipe são eficazes. Mas também para acompanhar como suas ações afetam a equipe de desenvolvimento. Ou seja, como eles moldam a experiência do usuário do funcionário (UX). Portanto, neste artigo, apresentamos estatísticas e métricas que o Scrum Master deve acompanhar.

Estatísticas e métricas importantes para o scrum master – índice:

1. Medindo os resultados do trabalho da equipe de desenvolvimento
2. Monitorando a experiência do usuário dos funcionários Desenvolvedores
3. Resumo

Medindo os resultados do trabalho da equipe de desenvolvimento

As estatísticas e métricas mais usadas que o Scrum Master deve acompanhar são aquelas que descrevem o ritmo e o fluxo da execução da tarefa. Estes são o Burnup Chart, o Burnup Chart e o Cumulative Flow Chart. Isso mede o desenvolvimento do produto e a eficácia da equipe. Cada um permite que você aborde esses problemas de um ângulo diferente, por isso é uma boa ideia mostrá-los juntos. São ferramentas úteis para avaliar o progresso em diferentes escalas, durante um Sprint, bem como todo o processo de desenvolvimento do produto.

Gráfico de Burndown

O gráfico de burndown mostra ao Scrum Master e ao Time de Desenvolvimento quanto trabalho foi feito e quanto falta fazer. O eixo X mostra o tempo restante para concluir o trabalho. O eixo Y mostra a quantidade de trabalho a ser feito que foi planejado no Sprint Backlog ou Product Backlog.

Este gráfico também ajuda a determinar a velocidade da equipe de desenvolvimento, à qual também dedicaremos um artigo separado. Aqui mencionaremos apenas que é uma quantidade média de trabalho realizado durante um Sprint.

Esta ferramenta simples permite ao Scrum Master não apenas ver quão eficientemente a equipe está trabalhando. Também ajuda a responder a perguntas:

• Que parte do trabalho já foi concluída?
• Quantas tarefas faltam para completar?
• Quanto tempo levará para desenvolver o Produto?

Ao utilizar o Burndown Chart, o Scrum Master precisa ter em mente que não é a única ferramenta para avaliar estatisticamente o progresso da equipe. Funciona melhor para projetos onde o escopo de trabalho é fixo e conhecido. Não funciona bem com a criação de soluções muito inovadoras com um novo Cliente. Então a quantidade de trabalho a ser feito em todo o projeto – que é o conteúdo do Product Backlog – pode mudar significativamente durante o projeto, dificultando o uso do Burndown Chart.

Gráfico de queima

O gráfico de Burnup é o inverso do gráfico de Burndown discutido acima. Aqui também, o eixo Y mostra a quantidade de trabalho restante a ser feito. O eixo X, por outro lado, mostra o tempo de conclusão expresso em número de Sprints ou em datas.

No entanto, o Scrum Master usa o Burnup Chart para um propósito ligeiramente diferente. Isso porque não apenas ajuda você a medir o progresso do produto e o progresso da equipe. Essa métrica também avalia como o escopo do trabalho em um projeto muda ao longo do tempo. Portanto, funciona bem para projetos com escopo variável.

O Burnup Chart também é uma ferramenta de planejamento que está se tornando mais eficaz ao longo do tempo. Ele fornece respostas para a questão de quanto trabalho a equipe de desenvolvimento deve fazer no próximo Sprint.

Diagrama de fluxo cumulativo

O terceiro tipo de diagrama que é muito frutífero no trabalho do Scrum Master com o Time de Desenvolvimento é o Diagrama de Fluxo Cumulativo. Apresenta a análise de quão estável é o ritmo e a produtividade da Equipe de Desenvolvimento. O layout de seus eixos é o mesmo do Burnup Chart, por isso é frequentemente referido como sua versão mais complexa.

No entanto, o diagrama de fluxo cumulativo não serve apenas para determinar o número de tarefas concluídas em um determinado período de tempo. Também leva em conta o número de tarefas que estão esperando na fila para execução. Graças a isso, permite diagnosticar os chamados “gargalos” – momentos do processo que retardam a criação de um produto.

Esse recurso de diagnóstico o torna uma das métricas mais úteis nas mãos do Scrum Master. Isso porque permite reorganizar o trabalho de forma a distribuir a força do Time de Desenvolvimento de forma diferente e evitar tempo de inatividade.

Monitorando a experiência do usuário dos funcionários Desenvolvedores

A manutenção regular e meticulosa e a análise de estatísticas são uma parte essencial do trabalho eficaz de um Scrum Master. No entanto, ele deve ter em mente primeiro a experiência de usuário dos desenvolvedores, ou seja, a forma como eles percebem o trabalho no Time Scrum. No entanto, não é a qualidade das métricas que decide, mas a forma como o Scrum Master as utiliza.

Se as estatísticas forem mantidas de acordo com os princípios do Scrum – elas são transparentes, públicas e compreensíveis para os Desenvolvedores envolvidos – elas podem ser uma forma de motivar a equipe a trabalhar com mais eficiência ou de recompensá-los por ótimos resultados. No entanto, as estatísticas podem funcionar como uma ferramenta para pressionar o Time de Desenvolvimento. Então suas indicações tornam-se geradoras de acusações e ressentimentos. Eles podem contribuir para deteriorar o moral da equipe e prejudicar as práticas de trabalho em equipe.

O segundo fator importante da experiência do colaborador dos Desenvolvedores, que o Scrum Master que trabalha com ferramentas estatísticas tem que cuidar, é a forma de gerenciar seu tempo. Isso porque o Scrum Master precisa ter tempo suficiente para cuidar do Time de Desenvolvimento. Por esse motivo, no caso de um projeto grande, vale a pena considerar a inclusão de uma pessoa adicional no Time Scrum. Ele/ela atuará como gerente de projeto e cuidará das métricas. Graças a isso, aliviará o Scrum Master – e até certo ponto o Product Owner – das tarefas que o distraem de trabalhar com o Time de Desenvolvimento.

Estatísticas e métricas - resumo

O Scrum Master deve acompanhar as estatísticas básicas que descrevem o trabalho do Time de Desenvolvimento. Sua interpretação habilidosa aumenta a chance de identificar rapidamente problemas no trabalho da equipe e reagir a eles. No entanto, mais importante do que manter os gráficos é o que o Scrum Master faz com eles. Eles não devem tratar as métricas como uma ferramenta para avaliar a equipe, mas sim tratá-las como uma ajuda útil para motivar a equipe e diagnosticar sua própria maneira de fazer as coisas. Isso porque as métricas só serão ferramentas úteis se ajudarem a facilitar os processos de melhoria da Equipe e do Produto.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto