Como acompanhar projetos Scrum com Burnup e Burndown? 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.
Ouça este artigo!
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ória | Pontuação | História | Pontuação | História | Pontuação |
| Alfa | 13 | Foxtrot | 5 | Kilo | 13 |
| Beta | 8 | Golf | 5 | Lima | 20 |
| Charlie | 5 | Hotel | 3 | Mike | ? |
| Delta | 3 | Índia | 2 | Novembro | ? |
| Eco | 8 | Juliet | 3 | Oscar | ? |
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.
“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:
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).
“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:
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:
Perceba que o escopo variou ao longo do projeto, o que é um fato. Isso acontecerá.
- Primeiro, teve um aumento da Sprint 1 para a 2;
- estabilizou entre as sprints 2 e 4;
- aumentou mais uma vez na Sprint 5;
- 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.
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?
É normal o backlog ficar estático?
Backlog estático é demonstrado por um gráfico que ficaria mais ou menos assim:
Não! Não é normal. Pode inclusive ser um grande problema. Algumas possibilidades:
- Foi feita uma estimativa no início do projeto e nunca mais ninguém a viu.
- Apertem os cintos, o Product Owner sumiu.
- O projeto é irrelevante e ninguém está pedindo nada.
- 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 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:
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ória | Pontuação | Quantidade de Tarefas |
| Alfa | 13 | 40 |
| Beta | 8 | 20 |
| Charlie | 5 | 14 |
| Delta | 3 | 9 |
| TOTAL | 29 | 83 |
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:
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 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 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!
