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 da Equipe de Desenvolvimento. Apesar de sua simplicidade, sua interpretação pode fornecer informações valiosas para toda a Equipe Scrum. Leia este artigo para descobrir como criar e interpretar 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 propósito é o Gráfico de Burndown.
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 da sprint ideal e, em seguida, marque o número de tarefas realisticamente concluídas para cada dia. Embora essa solução seja encantadora e envolva a equipe, não é muito prática. Também não é necessariamente adequada para equipes remotas.
Portanto, 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 uma determinada funcionalidade do produto, e sua contribuição é refletida no Gráfico de Burndown.
Com as ferramentas certas, também é possível escalar livremente o gráfico. Isso dá uma visão da combustão não apenas no nível de uma determinada Sprint, mas também na escala de um trimestre ou do projeto inteiro.
Um fator importante a considerar ao escolher uma ferramenta para criar um Gráfico de Burndown é sua acessibilidade a todos os membros da Equipe 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. Falar sobre a queima durante o Daily Scrum faz os Desenvolvedores pensarem sobre as maneiras como trabalham e o estado atual do Produto.
A questão da propriedade do Gráfico de Burndown é um tanto controversa. Por um lado, ele deve pertencer ao Scrum Master, porque é uma ferramenta para garantir que a Equipe esteja trabalhando de forma eficiente e de acordo com o plano. Por outro lado, ele deve permanecer nas mãos do Product Owner, porque reflete o progresso em direção a um Objetivo de Produto que é comunicado ao Cliente. Além disso, uma terceira parte que pode reivindicar sua propriedade é a Equipe de Desenvolvimento, já que o gráfico funciona como uma ferramenta interna para ela.
O Gráfico de Burndown é uma métrica essencial para avaliar a eficácia da Equipe de Desenvolvimento e se torna adotado por todos os membros da Equipe Scrum. É por isso que a transparência e a acessibilidade são cruciais. No entanto, seu próprio propósito é servir à Equipe. Ele deve fortalecer sua auto-organização, melhorar a motivação e dar uma imagem real do status do trabalho nas tarefas atribuídas a ela. Portanto, em teoria, cada membro da Equipe de Desenvolvimento pode atualizar o Gráfico de Burndown.
Na prática, no entanto, a tarefa de atualizar o Gráfico de Burndown geralmente recai sobre o 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, é recomendado delegar essa tarefa a um dos Desenvolvedores. Afinal, o gráfico deve ser uma medição honesta e interna do progresso do trabalho, conforme julgado pelos próprios Desenvolvedores.
Descrevemos a aparência do Gráfico de Burndown em detalhes em um artigo anterior. Aqui, apenas lembramos 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.
Para interpretar um Gráfico de Burndown, o fator chave não é apenas o plotagem regular da “combustão” real, ou seja, a execução de tarefas pela Equipe de Desenvolvimento. Igualmente importante para a imagem é sua comparação com a linha de combustão ideal (diretriz).
Ao comparar a linha de queima ideal com a redução real do trabalho 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á o Objetivo da Sprint ou o Objetivo do Produto a tempo. Segundo, para ter uma ideia de quando o trabalho será concluído mantendo o ritmo atual. Em outras palavras, o Gráfico de Burndown mostra o ritmo real das tarefas, e a linha ideal mostra a que ritmo a Equipe deve trabalhar para concluir as tarefas.
O Gráfico de Burndown também permite determinar um valor chamado Velocidade da Equipe de Desenvolvimento a longo prazo. Vamos dedicar um artigo separado a isso. Aqui, apenas mencionamos que é um valor determinado pela quantidade de trabalho realizado durante uma Sprint.
Graças ao fato de que o Gráfico de Burndown ilustra a comparação de uma linha de queima ideal com uma redução real no número de tarefas, ele permite estimar o ritmo de trabalho. E assim antecipar o risco de atrasos no projeto.
A velocidade da equipe geralmente é medida em unidades chamadas pontos de história. Isso define o número de histórias de usuário que foram realizadas. Essas podem exigir quantidades muito diferentes de trabalho.
É por isso que muitas Equipes Scrum usam uma medida baseada em tempo. Dependendo da escala, essas são dias ou horas-homem. Cada Desenvolvedor estima e, em seguida, registra a quantidade de tempo gasto em suas tarefas.
Outra opção é adotar tarefas como unidade. Essas são unidades um pouco 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 o progresso do trabalho no produto de uma maneira mais clara.
Independentemente da unidade de medida, vale a pena lembrar o princípio de calcular a velocidade da Equipe de Desenvolvimento. Em um determinado dia ou Sprint, apenas as tarefas que foram realmente concluídas contam. Isso significa que tarefas iniciadas serão contadas para o dia ou Sprint seguinte, mesmo que apenas o teste final esteja faltando.
Com as ferramentas de monitoramento de equipe disponíveis, criar um Gráfico de Burndown se torna uma tarefa fácil. A questão mais importante é garantir sua coerência, clareza e acessibilidade a todos os membros da Equipe Scrum.
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.
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…
Você sabe como começar uma ONG? Você tem pensado nisso? Você está ciente de quão…
Quanto maior a empresa, mais cargos de RH ela oferece, o que significa que às…
O que é análise de cargos? Você já ouviu esse termo, sabe o que precisa…