Compartilhe

Como acompanhar projetos Scrum com Burnup e Burndown

16/11/21 - 11 minutos de leitura

Para os times que utilizam Scrum há componentes que facilitam o acompanhamento do trabalho. Em especial, destaco os gráficos de acompanhamento do projeto: Burnup e Burndown. Neste artigo vou te ensinar a utilizá-los em dois níveis de granularidade: o andamento do projeto e o andamento da Sprint.

Gráfico de Burnup

O Gráfico de Burnup é muito interessante para avaliar a evolução dos projetos Scrum em relação ao esforço necessário para concluí-lo. Você utilizará três medidas: Esforço do Projeto; Esforço Planejado na Sprint; e Esforço Realizado na Sprint.

Métrica 1: Esforço do Projeto

A primeira é o esforço do backlog. Esta é a estimativa de esforço feita pelo Time de Desenvolvimento (Desenvolvedores) normalmente utilizando o Planning Poker. Digamos que temos um Backlog composto por 20 Histórias (itens que adicionam valor ao produto) e que foram assim pontuadas:

HistóriaPontuaçãoHistóriaPontuaçãoHistóriaPontuação
Alfa13Foxtrot5Kilo13
Beta8Golf5Lima20
Charlie5Hotel3Mike?
Delta3Índia2Novembro?
Eco8Juliet3Oscar?
Tabela 1: Histórias de um backlog com esforço estimado através da pontuação da técnica de Planning Poker.

Somando todas as histórias, teríamos um esforço estimado para o término do projeto igual a 88 Pontos de História (User Story Points). Uma pergunta que você pode fazer é: como tratar as histórias Mike, Novembro e Oscar que ainda não foram pontuadas? Aqui há algumas opções. 

A primeira é tratá-las como épicos que deverão ser fatiados no futuro para serem desenvolvidos. Quando o Time Scrum opta por essa opção, o comum é que os Desenvolvedores escolham uma pontuação que indique que a história é tão grande que ela deve ser tratada como um épico.

Como exemplo, digamos que esse time escolheu que toda história que for estimada com um total de 20 ou mais Pontos de Histórias deve ser fatiada em histórias menores pelo Product Owner antes de serem discutidas na Reunião de Planejamento (Sprint Planning).

Nesse caso, o esforço total do projeto seria igual a 88 (histórias pontuadas) + 60 (3 x 20 das histórias não pontuadas) que é igual a 148 Pontos de História.

A segunda abordagem, que eu particularmente prefiro, é não pontuar essas histórias e manter os 88 pontos. Nós somos ágeis e sabemos que o escopo do projeto mudará. Logo, 88 é a pontuação total sobre o que eu conheço até hoje. Amanhã, entrarão novas histórias. Algumas serão modificadas e outras serão descartadas.

Como acompanhar projetos Scrum com Burnup e Burndown 1
O início do Gráfico de Burnup. Apenas o esforço estimado para concluir os projetos Scrum

“Ah! Mas eu tenho que reportar para o meu gestor uma estimativa exata!” 

Perceba que essa frase é um paradoxo. Estimativa é estimativa, e por definição não poderá ser exata. Estimativa jamais será uma assertiva. Uma boa definição seria: cálculo aproximado de algo (prazo, custo, escopo, capacidade, retorno) baseado nas informações que temos até hoje.

E diria ainda mais. Somos ágeis, o escopo com certeza mudará. O ideal quando temos uma relação de cobrança de estimativa é sermos o mais transparentes possíveis. Não há atalhos e nem dados mágicos de onde poderemos tirar 100% de precisão.

>> Escopo Fechado, a ilusão. Principalmente a parte que fala sobre o Cone da Incerteza de Boehm

Métrica 2: Esforço Planejado na Sprint

Em todo o Planejamento da Sprint (Sprint Planning), o time se compromete em transformar ideias (histórias de usuário) em um incremento do produto / serviço potencialmente entregável para o cliente. Se o time utilizar o Planning Poker, esses itens de valor são associados a uma estimativa de esforço expressa em pontos de histórias. 

Todas as histórias que o time selecionou compõem o Backlog da Sprint (Sprint Backlog). O somatório de todos os pontos de todas as histórias selecionadas também é marcado no Gráfico de Burnup do Projeto. 

No exemplo, digamos que a vazão (comumente chamada de velocidade) desse time seja igual a 30 pontos de história por sprint. E eles se comprometeram em entregar 29 pontos de histórias na primeira Sprint referentes aos itens (Alfa, Bravo, Charlie e Delta).

O gráfico então ficaria assim:

Como acompanhar projetos Scrum com Burnup e Burndown 2
Planejamento da Sprint 1

Estimar quando o projeto vai acabar

Com base nessas informações, seria possível estimar o término do projeto? Sim e não. Imaginando que o time faz 30 pontos de história por Sprint e o Backlog possui 88 pontos de história no total, esse projeto acabaria em 3 sprints (3 x 30 = 90).

Como acompanhar projetos Scrum com Burnup e Burndown 3

“Mas Avelino, você se comprometeria com o prazo de 3 sprints para acabar o projeto?”

JAMAIS! Esse backlog vai mudar! O desempenho raramente é tão linear. Coisas inesperadas acontecem. O risco desse “prazo” furar é muito alto. 

“Mas nós temos no máximo três sprints para entregar esse projeto!”

Ótimo, então vamos cortar o escopo. O que não é essencial para eu entregar em três sprints. Tudo que não se encaixar nessa categoria deve ser DESCARTADO.

“Mas puxa vida, eu queria tanto um gráfico em 3D girando tipo Google Earth”.

Sinto muito, nessas 3 sprints te entregaremos um planilhão em que você terá os mesmos dados, mas terá que fazer uns filtros e umas pesquisas. É o que dá, no tempo que temos. 

Métrica 3: Esforço Realizado na Sprint

A última informação contida no gráfico de Burnup é o esforço que foi realizado no final da Sprint. Planejamos entregar 29, porém não conseguimos desenvolver as histórias (Charlie e Delta). Logo o esforço realizado foi igual a 21 (Charlie = 5 pontos e Delta = 3 Pontos).

O gráfico ficaria assim:

Como acompanhar projetos Scrum com Burnup e Burndown 4

O nosso objetivo é fazer com que a linha verde encoste na linha azul o mais breve possível. Todavia, CUIDADO! Não renuncie à qualidade do produto ou serviço por velocidade. 

Abrir mão da qualidade é a mesma coisa que cuspir para cima.

Rodrigo de Toledo

“Mas tivemos uma história que ficou ½ feita. Informo que realizei a metade dela?” 

Depende... Particularmente, eu prefiro considerá-la 0% feita. Meio pronta pode, em uma segunda análise, se tornar 0,1% pronta. O fato dela não ser entregue, significa que ela gera $0,00 de resultado. Mas isso não é uma regra, experimente outras formas e deixe um comentário aqui no final do artigo. 

“Quando marcar o esforço realizado?”

 Preferencialmente antes da Retrospectiva da Sprint (Sprint Retrospective)

Terminando o projeto

No final do seu projeto, o gráfico seria: 

Como acompanhar projetos Scrum com Burnup e Burndown 5
Término do Projeto na Sprint 6 apresentado Gráfico de Burnup

Perceba que o escopo variou ao longo do projeto, o que é um fato. Isso acontecerá.

  1. Primeiro, teve um aumento da Sprint 1 para a 2;
  2. estabilizou entre as sprints 2 e 4;
  3. aumentou mais uma vez na Sprint 5;
  4. e, por fim, na Sprint 6 teve escopo descartado. 

Como analisar o gráfico

Meu projeto está terminando?

Quando a linha de Esforço Realizado (verde) encostar na linha de esforço do projeto (azul), o projeto encerrou. Esse toque pode acontecer de duas formas: o time conseguiu entregar todo o escopo do projeto (linha verde tocou na linha azul). Outra forma, muito mais comum: o escopo desnecessário foi descartado e a linha azul tocou a linha verde.

 

Como acompanhar projetos Scrum com Burnup e Burndown 6

Meu projeto está atrasado?

Toda vez que a linha de Esforço Planejado na Sprint (laranja) estiver acima do Esforço Realizado na Sprint (verde), podemos perceber que naquele momento o projeto está atrasado. Nós não estamos conseguindo entregar o escopo prometido. No nosso exemplo, esse fato aconteceu na Sprint 1 e Sprint 2.

Alguns questionamentos que o Scrum Master pode levar para os Desenvolvedores:

  • Será que estamos nos comprometendo mais do que a nossa capacidade de entregar?
  • Há alguma coisa que está atrapalhando a construção do incremento do nosso produto ou serviço?

Meu projeto está adiantado?

Toda vez que a linha do Esforço Realizado na Sprint (verde) estiver acima do Esforço Planejado na Sprint (laranja), o projeto está adiantado. No exemplo, isso aconteceu na Sprint 4. 

A princípio pode parecer uma coisa boa, mas pode ligar alguns sinais de alerta também:

  • Será que estamos nos comprometendo com um esforço muito menor do que a nossa capacidade?
  • Será que a nossa estimativa está adequada para o desafio? Estaria ela superestimada?
Como acompanhar projetos Scrum com Burnup e Burndown 7

É normal o backlog ficar estático?

Backlog estático é demonstrado por um gráfico que ficaria mais ou menos assim:

Como acompanhar projetos Scrum com Burnup e Burndown 8
Burnup com o Esforço do Projeto estático

Não! Não é normal. Pode inclusive ser um grande problema. Algumas possibilidades:

  1. Foi feita uma estimativa no início do projeto e nunca mais ninguém a viu.
  2. Apertem os cintos, o Product Owner sumiu.
  3. O projeto é irrelevante e ninguém está pedindo nada.
  4. Cascatágil, Fake Agile, FrÁgil, FalsÁgil, ou seja, lá como você queira chamar. O projeto é feito em Sprints, tem PO, Scrum Master, Desenvolvedores, quem sabe até um “Squad”. Todavia nada é entregue para o cliente, logo não há nenhum feedback para aperfeiçoar o produto. Se caiu neste caso, sinto em informar, mas você está experimentando o Castelo de Mentiras.

Gráfico de Burndown

O Burnup do Projeto é muito bom para acompanharmos o andamento do projeto. Enquanto o gráfico de Burndown é muito bom para acompanharmos o andamento da Sprint, o que também é muito importante.

Vamos utilizar a Sprint 1 do exemplo anterior (Projeto Zulu). O time selecionou 29 pontos de histórias para aquela Sprint. Digamos que o tamanho da Sprint é de 2 semanas (10 dias úteis). Podemos imaginar que esse time consumiria 2,9 pontos de história por dia (29 /10 = 2,9).

O gráfico começaria da seguinte forma:

Como acompanhar projetos Scrum com Burnup e Burndown 9
Planejamento diário de consumo de esforço durante a Sprint 1

Como medir o esforço realizado dia a dia? Há 3 formas comuns: Proporcional com estimativa do desenvolvedor; Proporcional com base na quantidade de tarefas concluídas; e Absoluto.

1. Proporcional com estimativa do desenvolvedor

A primeira baseia-se no andamento diário. Em toda reunião diária (Daily Meeting) você perguntaria para os desenvolvedores de cada história quantos pontos eles consumiram ao longo do dia anterior. Um exemplo de diálogo seria: 

Scrum Master: "Dessa história de 8 pontos, quantos vocês já realizaram?"

Desenvolvedor 1: "Uns 4 pontos."

Scrum Master: "E dessa história de 13 pontos?"

Desenvolvedora 2: "Uns 3 pontos. "

Scrum Master: "Começamos mais alguma outra? "

Desenvolvedora 3: "Não."

OK. O esforço de hoje foi igual a 7 pontos de história (4 + 3).

Você terá um gráfico próximo a este:

Como acompanhar projetos Scrum com Burnup e Burndown 10
Gráfico de Burndown da Sprint 1 utilizando o método proporcional por estimativa dos desenvolvedores

Há um ponto de atenção que temos que ter com esta escolha. Ela tem um fator humano subjetivo. É uma pessoa que está falando quanto já foi consumido, e a percepção dela pode não condizer com a realidade.

2. Proporcional com base na quantidade de tarefas concluídas

Outra forma seria utilizar um cálculo ainda proporcional, mas dessa vez baseado na quantidade de tarefas em que a história foi dividida e na quantidade de tarefas concluídas.

Aqui vale uma explicação importantíssima!

Uma História de Usuário para ser transformada em incremento de produto pode ser “quebrada” em tarefas técnicas com duração máxima de 1 dia. Muito cuidado, porque há ferramentas que colocam História de Usuário e Tarefa em um mesmo nível quando na verdade não estão.

Poderíamos dizer o seguinte: Um projeto é composto por Épicos e / ou Histórias de Usuário (sim, é possível ter um projeto sem épicos). Um épico pode ser fatiado em Histórias de Usuário.

Uma História de Usuário pode ser quebrada em tarefas técnicas. Há uma hierarquia aqui. Dá uma olhadinha no artigo Product Backlog: Épico, História de Usuário e Tarefas, em que nós tratamos o assunto e como algumas ferramentas enxergam essa hierarquia.

Digamos que as histórias foram quebradas em pequenas tarefas, conforme a tabela abaixo:

HistóriaPontuaçãoQuantidade de Tarefas
Alfa1340
Beta820
Charlie514
Delta39
TOTAL2983
Tabela com o Sprint Backlog da Sprint 1 Histórias selecionadas e em quantas tarefas cada uma foi quebrada.

No dia 1, os desenvolvedores fizeram 8 tarefas da Alfa e 9 da Beta. Totalizando 17 tarefas, ou aproximadamente 20% do total de tarefas. Por regra de 3,20% do Esforço da Sprint (29 pontos de história) seria igual a aproximadamente 6 pontos de história.

O gráfico, então, ficaria assim:

Como acompanhar projetos Scrum com Burnup e Burndown 11
Gráfico de Burndown da Sprint 1 utilizando o método proporcional por quantidade de tarefas

Aqui também há um ponto de atenção importante. Tarefas são voláteis. Os desenvolvedores podem criar tarefas ou eliminar as que já estão no sprint backlog se perceberem a necessidade ou desnecessidade de realizar atividades durante a sprint para concluir aquela história de usuário.

“Ah! Então depois que a Sprint for iniciada os desenvolvedores estão proibidos de criar, modificar ou excluir tarefas!” Não. É o método que serve o time ou o time que serve o método? Trabalhamos com a volatilidade dela e adaptamos o método às necessidades do time.

Na prática, é apenas o valor percentual de vazão (velocidade) que mudará, pois o esforço das histórias de usuário permanece o mesmo.

Independentemente do método proporcional que você utilizou, o resultado da conclusão de uma sprint poderia ser:

Como acompanhar projetos Scrum com Burnup e Burndown 12
Término da Sprint com o esforço planejado e realizado

Como Interpretar esse gráfico? 

No dia 1, o time rendeu bem, a linha do realizado (verde) estava abaixo do planejado (laranja). No dia 2, os desenvolvedores fizeram o que foi planejado até então (linhas sobrepostas).

Mas já há uma queda na produtividade visto que no dia anterior eles estavam entregando 2 pontos a mais do que o planejado. Do dia 1 para o dia 2, o time entregou apenas 1 pontinho. 

Do dia 3 em diante, o time começa a ficar atrasado, pois a linha do realizado (verde) está acima do planejado (laranja). Esse atraso não conseguiu ser recuperado.

Entre os dias 5 e 6, nada foi entregue. No final da Sprint, alguma história não terminou, pois faltam 6 pontos.  

O que aconteceu? O gráfico só alerta o problema, ele não resolve o problema. Teríamos que estar junto dos desenvolvedores para saber o que estava acontecendo. Não dá para ser um facilitador distante do time. 

Uma boa métrica é um convite a uma boa conversa!

Lucas de Barros Gomes

Agora, o que fazer nesses casos?

Caso você estivesse facilitando esse time, no dia 2 já teria ficado alerta. O dia 3 já seria uma boa mergulhar na Sprint e resolver os problemas (nem sempre é possível).

Do dia 6 em diante, a ideia seria só conter o raio da explosão (avisar gestores, stakeholders etc.). Pois a distância entre o realizado e planejado já é bem alta (60%). A partir desse dia, já seria perceptível a não conclusão de todas as histórias do backlog da Sprint. 

3. Absoluto

A outra forma de marcar o esforço realizado é contabilizar a história apenas quando ela for entregue de acordo com a Definição de Pronto (Definition of Done). O gráfico tende a ficar com uma “escada” já que os itens só são marcados quando totalmente concluídos.

Como acompanhar projetos Scrum com Burnup e Burndown 13
Gráfico de Burndown apresentando a evolução absoluta da Sprint

Como interpretar esse gráfico?

Entre o dia 1 e 3 o time fez suas tarefas técnicas, mas isso é irrelevante para esse modo de exibição. No dia 4, o time entregou a primeira história de usuário. Foi a Beta que tinha 8 pontos de história.

No dia 7 foi entregue a Alfa que tinha 13 pontos. Conforme exibido em todos os outros gráficos, as Histórias Charlie (5 pontos de história) e Delta (3 pontos de história) que estavam no Backlog da Sprint não foram concluídas.

Perceba que nos métodos proporcionais é mais fácil perceber durante a Sprint que teremos atrasos ou adiantamentos. Como o método absoluto só contabiliza histórias totalmente concluídas, essa percepção se torna mais difícil, principalmente em Sprints mais curtas.

O que fazer com as histórias não concluídas

Muito melhor do que dar uma resposta pronta, seria levar esses gráficos para retrospectiva e exibir o impacto da história não concluída. Vamos pensar juntos no que podemos fazer para evitar que isso aconteça?

Conclusão

Espero que tenha ajudado você a acompanhar os seus projetos Scrum. Sugiro que dê uma boa olhada também nos gráficos de CFD. Experimente e não esqueça de colocar aqui nos comentários as suas experiências. Também disponibilizo uma planilha para você utilizar nos seus projetos. Faça uma cópia, apague os dados de exemplo e comece a gerar seus gráficos.

Planilha com gráficos de Burnup e Burndown

Quer aprender mais sobre Scrum?

Que tal fazer o treinamento de Certified Scrum Master com a certificação internacional pela Scrum Alliance? Nos vemos em breve!

Compartilhe

Escrito por

Avelino Ferreira Gomes Filho

Agile Expert e Trainer na K21


Avelino é formado e mestre em Ciência da Computação. Teve uma longa trajetória na T.I. começando como programador e chegando à gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis desde 2008. A partir de 2015 se dedicou a auxiliar outras empresas a adotar tais métodos. Atualmente é Agile Coach e Trainer na Knowledge 21.
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artigos relacionados

Scrum em restaurante: agilidade fora de TI
29/10/21
7 minutos de leitura
Gestão de Pessoas
10 habilidades do Agile Coach: soft skills e hard skills
20/08/21
5 minutos de leitura
Gestão de Pessoas
RH: 12 passos para construir seu super time
28/01/21
5 minutos de leitura
Scrum Master habilita o time a aumentar sua efetividade
17/12/19
2 minutos de leitura

    Receba mais conteúdos K21

    Deixe seu nome e email que nós te deixamos por dentro de tudo que rola por aqui.

    Ao informar meus dados, eu concordo com a Política de Privacidade.