Guia Scrum | 32. Vantagens e desvantagens do gráfico de burndown

O gráfico de queima tem muitos benefícios. É uma das principais ferramentas de métricas no Scrum por vários motivos. É fácil de criar, dimensionar e ler. No entanto, também tem desvantagens que o tornam não uma ferramenta universal. No artigo de hoje, abordamos o tópico das desvantagens e vantagens do gráfico de burndown.

Vantagens e desvantagens do gráfico de burndown – índice:

1. Introdução
2. Vantagens do gráfico Burndown
3. Desvantagens do gráfico Burndown
4. Resumo

Introdução

Já escrevemos sobre o que é, como criar e interpretar um gráfico de burndown em artigos anteriores. Hoje vamos nos concentrar nas vantagens e desvantagens do gráfico de burndown. No entanto, a maioria deles não está oculta no próprio gráfico simples. Ao contrário, estão relacionadas às formas de usar o gráfico de burndown para motivar o Time de Desenvolvimento, pois descrevem os resultados de seu trabalho e fortalecem a auto-organização.

Vantagens do gráfico Burndown

O gráfico de queima permite visualizar o progresso do seu projeto. Sua legibilidade e simplicidade o tornam tão popular. É por isso que é uma boa ideia que o Burn Chart não seja apenas uma métrica constantemente atualizada escondida em uma ferramenta digital de gerenciamento de projetos. Se possível, vale a pena torná-lo um ponto de referência para a equipe de desenvolvimento visível no local de trabalho físico. Seja na forma de uma visualização na tela ou de um esboço desenhado à mão.

Motiva a equipe de desenvolvimento

A transparência do gráfico de queima pode torná-lo uma ferramenta para motivar a equipe de desenvolvimento a trabalhar com eficiência. Atingir o ponto “zero” em cada Sprint pode se tornar uma meta ambiciosa da Equipe, pela qual são dadas recompensas – de acordo com os princípios da gamificação empresarial.

A visibilidade de um gráfico de burndown atualizado e mantido de forma interessante também pode aumentar o espírito de cooperação e auto-organização. Afinal, a métrica é uma medida de trabalho em equipe. Não mostra exatamente quem fez – ou não – as tarefas planejadas, apenas os resultados alcançados.

Mede o trabalho real realizado

Os desenvolvedores decidem quantas tarefas executarão em um determinado Sprint. Quanto mais experiente for a equipe, mais precisamente eles devem prever suas ações. E o gráfico bur-down reflete o progresso real do Sprint.

Assim, a vantagem do gráfico de queima não é tanto medir a quantidade objetiva de trabalho realizado, mas a proporção de tarefas planejadas e concluídas. Assim, os Desenvolvedores aprendem gradativamente como planejá-los e podem estimar suas capacidades com cada vez mais precisão e eliminar erros repetitivos.

Ele combina com outras ferramentas

Uma das vantagens significativas do gráfico burndown diz respeito à sua versatilidade em combinar com outras ferramentas. As seguintes ferramentas podem ser aplicadas a:

• analisando o trabalho da equipe de desenvolvimento
• visualizar o progresso do trabalho no Produto
• estimando o orçamento do projeto

Por exemplo, neste último caso, o uso do Gráfico Burndown da Escala do Projeto permite uma comparação do orçamento planejado e real para todo o projeto.

Desvantagens do gráfico Burndown

Apesar de todas as vantagens do gráfico Burndown descritas acima, ele pode se tornar uma fonte de confusão para a equipe de desenvolvimento. No entanto, o que frequentemente chamamos de “falhas” do gráfico de burndown não se deve a imperfeições da própria ferramenta. Os problemas descritos abaixo dizem respeito à maneira de implementar o gráfico de burndown e não ao seu design. Abaixo estão as falhas que podem interferir na representação do progresso da equipe de desenvolvimento dessa maneira.

“O Fator Humano”

Os gráficos não podem ser uma medida absoluta do progresso de uma equipe. São apenas ferramentas para aplicar de maneiras diferentes, mais ou menos habilidosas. Podemos considerá-lo como uma desvantagem (ou vantagem) não apenas do gráfico de burndown, mas também de outras medidas de desempenho da equipe.

Para criar um gráfico de burndown, você precisa que outras pessoas insiram dados. Em outras palavras, os Desenvolvedores colocam o tempo de conclusão da tarefa no gráfico. Eles podem ter alongado ou encurtado um pouco – seja por falta de atenção ou querendo melhorar as coisas para a equipe. Os desenvolvedores às vezes também esquecem de registrar seu tempo. Ou deixe o timer ligado. Isso faz com que o tempo de trabalho se estenda para várias horas. E depois de descobrir o erro, é difícil reconstruir seu verdadeiro curso.

Mudanças na lista de pendências da Sprint

O Sprint Backlog não deve ser modificado após o início de um Sprint. No entanto, na prática, essas mudanças ocorrem com bastante frequência. Eles resultam de mudanças nos requisitos das Partes Interessadas. Ou problemas imprevistos que os Desenvolvedores encontram.

Isso faz com que o gráfico de burndown seja dimensionado. Isso ocorre porque o tempo necessário para concluir as tarefas permanece o mesmo. No entanto, a escala de tarefas restantes aumenta. Isso pode dar uma impressão enganosa de que o Time de Desenvolvimento planejou incorretamente o trabalho a ser feito em um determinado Sprint. Ou que funciona muito devagar.

As alterações no Sprint Backlog também podem resultar de tarefas que foram agendadas para conclusão muito rápida. Em tal situação, a equipe de desenvolvimento geralmente decide aumentar o número de tarefas. Isso, por sua vez, pode resultar em não completá-los a tempo. Além disso, conflitos podem surgir da sobreposição de tarefas restantes do Sprint anterior com novas tarefas agendadas para serem concluídas pelos Stakeholders e Product Owners.

Alterações no Backlog do Produto

Grandes mudanças no Product Backlog podem atrapalhar a forma do gráfico de queima. E, assim, falsificar fortemente a imagem do progresso do trabalho e da eficácia da equipe. Isso acontece quando novas histórias de usuário aparecem. E aqueles que estão próximos da fase de implementação são muitas vezes divididos em partes menores. Acontece também que o Cliente desiste de algumas funcionalidades do Produto.

Portanto, ao interpretar o quadro de queimadura, deve-se pautar-se pelo conhecimento e experiência na avaliação do desempenho da Equipe. E também levar em conta a variabilidade do Backlog. Se o gráfico não for a única métrica utilizada para avaliar o desempenho, os outros gráficos permitirão ter uma visão mais completa do andamento do trabalho.

Resumo

O gráfico de burndown pode contribuir significativamente para a motivação do Time de Desenvolvimento. Isso ocorre porque fornece uma medida do trabalho real realizado no plano. Além disso, sua combinação com outras ferramentas métricas pode ser uma fonte de conhecimento valioso sobre o trabalho da Equipe e o planejamento do Produto.

Ao aplicar cuidadosamente os princípios do Scrum, você pode evitar possíveis problemas com o burndown. O mais importante é adaptar as ferramentas para manter o gráfico acompanhando o trabalho real do Time Scrum, bem como minimizar as mudanças no Sprint e no Product Backlog, sobre os quais escrevemos mais neste artigo.

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