Guia Scrum | 31. Como criar e interpretar um gráfico de burndown?

Um gráfico de burndown é relativamente fácil de criar. Existem muitas ferramentas disponíveis para gerá-lo a partir do trabalho registrado pelos membros do Time de Desenvolvimento. Apesar de sua simplicidade, sua interpretação pode fornecer informações valiosas para todo o Time Scrum. Leia este artigo para descobrir como criar e interpretar um gráfico de burndown.

Como criar e interpretar um gráfico de burndown? - índice:

1. Como criar um gráfico de burndown?
2. Quem é responsável pelo gráfico de burndown?
3. Como interpretar um gráfico de burndown?
4. Gráfico de burndown real e ideal
5. Selecionando a unidade de medida
6. Resumo

Como criar um gráfico de burndown?

A Equipe de Desenvolvimento deve monitorar seu trabalho diário. Esta é a base não apenas para avaliar sua eficácia, mas também para melhorá-la. E uma das ferramentas mais simples e comprovadas para esse fim é o gráfico de queimadura.

Você pode criá-lo manualmente desenhando um sistema de coordenadas em um pedaço de papel. No eixo Y, você precisa plotar a quantidade de trabalho expressa em uma unidade escolhida, por exemplo, pontos de história. No eixo X, desenhe uma escala indicando os dias consecutivos da Sprint. Desenhe uma linha do sprint ideal e marque o número de tarefas concluídas de forma realista para cada dia. Embora essa solução seja charmosa e engaje a equipe, não é muito prática. Também não é necessariamente adequado para equipes remotas.

Portanto, os meios digitais de criar um gráfico de burndown são muito mais comuns. Muitas ferramentas para registrar o trabalho em tarefas distribuídas entre os membros da equipe vêm com uma opção para criar automaticamente um gráfico de burndown. Então, tudo o que um desenvolvedor precisa fazer é marcar o início e o fim do trabalho em um recurso específico do produto, e sua contribuição é refletida no gráfico de gravação.

Com as ferramentas certas, também é possível dimensionar livremente o gráfico. Isso fornece uma visão da combustão não apenas no nível de um determinado Sprint, mas também na escala de um quarto ou de todo o projeto.

Um fator importante a ser considerado ao escolher uma ferramenta para criar um gráfico de burndown é sua acessibilidade a todos os membros do Time Scrum. A visibilidade do gráfico de burndown para toda a equipe de desenvolvimento é um fator motivacional chave. Igualmente importante é uma olhada diária na linha que mostra o trabalho restante a ser feito. Falando sobre burn-in durante a Daily Scrum, , faz com que os desenvolvedores pensem sobre as formas como trabalham e o estado atual do produto.

Quem é responsável pelo gráfico de burndown?

A questão da propriedade do gráfico de queima é um tanto controversa. Por um lado, deve pertencer ao Scrum Master, pois é uma ferramenta para garantir que a Equipa está a trabalhar de forma eficiente e de acordo com o planeado. Por outro, deve permanecer nas mãos do Product Owner, pois reflete o progresso em direção a uma meta do produto que é comunicada ao cliente. Além disso, um terceiro para reivindicar sua propriedade é a equipe de desenvolvimento, pois o gráfico funciona como sua ferramenta interna.

O gráfico de burndown é uma métrica essencial para avaliar a eficácia do Time de Desenvolvimento e passa a ser adotado por todos os membros do Time Scrum. É por isso que a transparência e a acessibilidade são cruciais. No entanto, seu propósito é servir à Equipe. Supõe-se que fortaleça sua auto-organização, melhore a motivação e forneça uma imagem real do status do trabalho nas tarefas que lhe são atribuídas. Portanto, em teoria, cada membro da equipe de desenvolvimento pode atualizar o gráfico de queima.

Na prática, no entanto, a tarefa de atualizar o gráfico de burndown geralmente cabe ao Scrum Master. Isso acontece especialmente no início de seu trabalho com uma nova equipe de desenvolvimento, quando a velocidade da equipe ainda é variável e difícil de estimar. No entanto, é recomendável delegar essa tarefa a um dos Desenvolvedores. Afinal, o gráfico pretende ser uma medida honesta e interna do andamento do trabalho conforme julgado pelos próprios Desenvolvedores.

Como interpretar um gráfico de burndown?

Descrevemos a aparência do gráfico burndown em detalhes em um artigo anterior. Aqui, vamos apenas lembrá-lo que o eixo X mostra o tempo restante para concluir o trabalho. Por outro lado, o eixo Y mostra a quantidade de trabalho restante a ser feito.

Gráfico de burndown real e ideal

Para interpretar um gráfico de burndown, o fator chave não é apenas a plotagem regular da “combustão” real, ou seja, a execução de tarefas pelo Time de Desenvolvimento. Igualmente importante para a imagem é sua comparação com a queda ideal da linha de combustão (diretriz).

Ao comparar a linha de queima ideal com a redução de trabalho no mundo real marcada no gráfico de burndown, dois parâmetros muito importantes podem ser avaliados. Primeiro, para ver se o trabalho continua no ritmo atual, a Equipe de Desenvolvimento cumprirá a Meta do Sprint ou a Meta do Produto no prazo. Segundo, para ter uma ideia de quando o trabalho será concluído, mantendo o ritmo atual. Em outras palavras, o gráfico de queima mostra o ritmo real das tarefas, e a linha ideal mostra em que ritmo a Equipe deve trabalhar para concluir as tarefas.

O gráfico de queima também permite determinar um valor chamado Development Team Velocity a longo prazo. Vamos dedicar um artigo separado a ele. Aqui vamos apenas mencionar que é um valor determinado pela quantidade de trabalho realizado durante um Sprint.

Graças ao fato de que o gráfico de queima ilustra a comparação de uma linha de queima ideal com uma diminuição real no número de tarefas, permite estimar o ritmo de trabalho. E assim antecipar o risco de atrasos no projeto.

Selecionando a unidade de medida

A velocidade da equipe geralmente é medida em unidades chamadas pontos de história. Ele define o número de histórias de usuário que foram realizadas. Estes podem exigir quantidades muito diferentes de trabalho.

É por isso que muitos times Scrum usam uma medida baseada no tempo. Dependendo da escala, são dias ou horas-homem. Cada desenvolvedor estima e registra a quantidade de tempo gasto em suas tarefas.

Outra opção é adotar as tarefas como uma unidade. Estas são unidades ligeiramente maiores, que por sua vez recebem um valor expresso em pontos de história, ou em dias ou horas-homem. É uma unidade que permite ao cliente apresentar de forma mais clara o andamento do trabalho no produto.

Independente da unidade de medida, vale lembrar o princípio do cálculo da velocidade do Time de Desenvolvimento. Em um determinado dia ou Sprint, apenas as tarefas que foram realmente concluídas contam. Isso significa que as tarefas iniciadas serão contadas para o próximo dia ou Sprint, mesmo que apenas o teste final esteja faltando.

Resumo

Com as ferramentas de monitoramento de equipe disponíveis, criar um gráfico de burndown torna-se uma tarefa fácil. A questão mais importante é garantir sua coerência, clareza e acessibilidade a todos os membros do Time Scrum.

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

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