O Gráfico de Burndown tem muitos benefícios. É uma das principais ferramentas métricas no Scrum por várias razões. É fácil de criar, escalar e ler. No entanto, também possui desvantagens que fazem dele uma ferramenta não universal. No artigo de hoje, abordamos o tema das desvantagens e vantagens do Gráfico de Burndown.
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 delas não está oculta no gráfico simples em si. Em vez disso, estão relacionadas às maneiras de usar o Gráfico de Burndown para motivar a Equipe de Desenvolvimento, pois descrevem os resultados de seu trabalho e fortalecem a auto-organização.
O Gráfico de Burndown permite que você visualize o progresso do seu projeto. Sua legibilidade e simplicidade o tornam tão popular. É por isso que é uma boa ideia que o Gráfico de Burndown não seja apenas uma métrica constantemente atualizada escondida em uma ferramenta de gerenciamento de projetos digital. 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 um esboço desenhado à mão.
A transparência do Gráfico de Burndown pode torná-lo uma ferramenta para motivar a Equipe de Desenvolvimento a trabalhar de forma eficiente. Alcançar o ponto “zero” em cada Sprint pode se tornar um objetivo ambicioso da Equipe, para o qual recompensas são dadas – 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 do trabalho em equipe. Não mostra exatamente quem completou – ou não – as tarefas planejadas, apenas os resultados alcançados.
Os desenvolvedores decidem quantas tarefas realizarão em uma determinada Sprint. Quanto mais experiente a Equipe, mais precisamente deve prever suas ações. E o gráfico de burndown reflete o progresso real da Sprint.
Assim, a vantagem do Gráfico de Burndown não é tanto medir a quantidade objetiva de trabalho realizado, mas a proporção de tarefas planejadas para tarefas concluídas. Assim, os desenvolvedores aprendem gradualmente a planejar e podem estimar suas capacidades de forma cada vez mais precisa e eliminar erros repetitivos.
Uma das vantagens significativas do Gráfico de Burndown diz respeito à sua versatilidade em se combinar com outras ferramentas. As seguintes ferramentas podem se aplicar a:
Por exemplo, neste último caso, o uso do Gráfico de Burndown da Escala do Projeto permite uma comparação do orçamento planejado e real para todo o projeto.
Apesar de todas as vantagens do Gráfico de 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 ferramenta em si. Os problemas descritos abaixo dizem respeito à forma de implementar o Gráfico de Burndown, em vez de seu design. Abaixo estão as falhas que podem interferir na representação do progresso da Equipe de Desenvolvimento dessa forma.
Gráficos não podem ser uma medida absoluta do progresso de uma equipe. Eles são apenas ferramentas a serem aplicadas de maneiras diferentes, mais ou menos habilidosas. Podemos considerar isso 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 de outras pessoas para inserir dados. Em outras palavras, os desenvolvedores registram o tempo de conclusão das tarefas no gráfico. Eles podem ter alongado ou encurtado um pouco – seja por desatenção ou por querer melhorar as coisas para a equipe. Os desenvolvedores também às vezes esquecem de registrar seu tempo. Ou deixam o cronômetro ligado. Isso faz com que o tempo de trabalho se estenda por várias horas. E após descobrir o erro, é difícil reconstruir seu curso real.
O Sprint Backlog não deve ser modificado após o início de uma Sprint. No entanto, na prática, tais mudanças ocorrem com bastante frequência. Elas resultam de mudanças nos requisitos dos Stakeholders. Ou problemas imprevistos que os desenvolvedores encontram.
Isso faz com que o Gráfico de Burndown seja escalado. 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 a Equipe de Desenvolvimento planejou incorretamente o trabalho a ser feito em uma determinada Sprint. Ou que está trabalhando muito lentamente.
Alterações no Sprint Backlog também podem resultar de tarefas que foram agendadas para conclusão muito rapidamente. Nessa situação, a Equipe de Desenvolvimento geralmente decide aumentar o número de tarefas. Isso, por sua vez, pode resultar na não conclusão delas a tempo. Além disso, conflitos podem surgir da sobreposição de tarefas restantes da Sprint anterior com novas tarefas agendadas para serem concluídas pelos Stakeholders e Product Owners.
Grandes mudanças no Product Backlog podem desestabilizar a forma do Gráfico de Burndown. E, assim, falsificar fortemente a imagem do progresso do trabalho e da eficácia da Equipe. Isso acontece quando novas User Stories aparecem. E aquelas que estão próximas da fase de implementação são frequentemente divididas em partes menores. Também acontece que o Cliente desiste de algumas funcionalidades do Produto.
Portanto, ao interpretar o Gráfico de Burndown, deve-se ser guiado por 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 usada para avaliar o desempenho, os outros gráficos permitirão ver uma imagem mais completa do progresso do trabalho.
O Gráfico de Burndown pode contribuir significativamente para a motivação da Equipe de Desenvolvimento. Isso 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 problemas potenciais com o Gráfico de Burndown. O mais importante é adaptar as ferramentas de manutenção do gráfico seguindo o trabalho real da Equipe Scrum, bem como minimizar mudanças no Sprint e no Product Backlog, sobre o que 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.
Como Gerente de Projetos, Caroline é uma 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 a tornam a melhor pessoa para transformar projetos complicados em realidade.
Como vender no Pinterest e por que você deveria fazer isso? Vender no Pinterest é…
Você é um freelancer procurando maneiras de promover seu portfólio? Hoje em dia, não apenas…
A gestão financeira digital e a contabilidade online tornaram-se cada vez mais populares nos negócios.…
Os estatutos de projeto são o pão e a manteiga da gestão de projetos. Eles…
Organizações de diversos setores constroem relacionamentos com potenciais funcionários, fornecedores e parceiros todos os dias.…
Existem muitas técnicas de gestão por aí. Algumas parecem intrincadas, enquanto outras são simples, mas…