Gráfico Burndown como ferramenta para avaliar riscos em Projetos Ágeis

O gerenciamento de riscos é uma disciplina fundamental utilizada durante todo o processo de desenvolvimento de um projeto. E você sabe por que, caro leitor? Porque, na verdade, tudo o que nós gerenciamos são riscos.  Vamos pensar um pouco: se preciso concluir uma tarefa no prazo estimado de um dia e planejo quais serão os passos necessários para concluir essa tarefa no prazo estabelecido, não estou gerenciando  meu tempo. Não se engane! Na verdade, o que você estou gerenciando é o risco de atrasar a conclusão daquela tarefa. Essa mesma linha de raciocínio pode ser utilizada em diversas outras situações.

Muitos acreditam que as metodologias ágeis ignoram completamente os riscos em um projeto. Nao é bem assim! O que acontece é que o manisfesto ágil aposta em valores que vão de encontro às crenças das metodologias tradicionais. Os riscos são vistos como inerentes aos projetos e são aceitos, mas nunca ignorados! Com suas pequenas iterações  e entregas constantes de produto potencialmente utilizável ao cliente, o time evita o maior risco que os projetos enfrentam: não entregar nada. Assim, as metologias ágeis buscam se antecipar à ocorrência dos riscos, o que prova que eles não são ignorados.

Hiren Doshi e Kane Mar publicaram, recentemente, alguns artigos sobre a análise do Gráfico de Burndown, apresentando que tipo de informações ou perguntas podemos extrair dele. Trata-se de “uma ferramenta importante para o acompanhamento do progresso de um time ágil e muitas informações podem ser extraídas do mesmo. Também podemos utilizá-lo para acompanhamento do projeto, produto ou releases” [HAZRATI, 2010].  A análise de Hiren Doshi foi baseada nas perguntas e no gráfico abaixo:

Em um gráfico de burndown eixo Y pode ter como unidade horas, semanas ou story points, enquanto o eixo X pode ser em dias ou sprints. É importante frisar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto ou organização, visto que cada unidade possui visões e objetivos diferentes.

“Burndown por horas e burndown por pontos tem propósitos diferentes!! Ninguém espera que um burndown por horas diga o quanto de valor foi entregue, mas apenas o acompanhamento do ritmo dirário do time. Os dois são importantes!” Alexandre Magno, CST

Podemos fazer uma análise do gráfico acima, o que nos trará subsídios para que possamos evitar que riscos futuros de projeto.

Observando a linha azul (linha 1) podemos visualizar um cenário não desejado. O time não conseguiu alcançar seus objetivos traçados durante a Sprint Planning, o que indica que o planejamento e/ou a execução não estão bons. Podemos citar algumas situações que podem contribuir para a construção deste cenário: planejamento de mais histórias do que a capacidade do time, alteração de prioridades durante o sprint ou uma falta de união do time. E quais são os riscos que este cenário apresenta?

• Atrasos na entrega de partes potencialmente utilizáveis do produto ao cliente;
• Desgastes com renegociação de prazos;

A linha roxa (linha 2) apresenta um cenário onde o time conseguiu atingir a meta, porém esteve longe do progresso ideal. A curva acentuada pode indicar que o time não atualizou suas estimativas de maneira adequada ou ainda que hisórias incompletas foram retiradas da sprint. Isso demonstra um time comprometido com o prazo, porém pouco interessado com a qualidade do processo e do produto gerado. O principal risco envolvido nesse cenário é a insatisfação do cliente com relação ao que foi prometido e o que realmente foi entregue. A consequência imediata pode ser desgaste na relação com o cliente, bem como eventuais quebras de contratos.

Por fim, a linha verde (linha 3) demonstra um cenário ideal, onde planejamento e execução foram bem feitos. O time é auto-organizado e bastante adaptável a mudanças. Porém, como diria o poeta,  nem tudo são flores! Sempre existe algo que pode ser melhorado e isso deve ser feito durante a Sprint Retrospective, que envolve uma análise dos pontos positivos e negativos apresentados pelo time durante a Sprint.

Bem o objetivo desse post foi demonstrar que o Gráfico de Burndown pode ser uma ótima ferramenta de apoio na gestão de riscos de projetos ágeis.  E para tanto, ela deve ser utilizada de acordo com as necessidades que o negócio ou organização necessita. Caso o leitor queira se aprofundar um pouco mais no assunto, existe um artigo publicado na LOCAWEB que faz uma outra análise sobre o Burndown focada em mudanças na sprint. Há também um outro artigo muito interessante de Kane Mar, Seven common Sprint Burndown graph signatures, onde ele separa o Burndown em sete categorias apresentando as nuances desses diversos cenários. Vale a pena conferir!

DOSHI, Hiren. Sprint Burndown says a lot about your scrum team... PracticeAgile  Software Development, 2010.
HAZRATI, Vikas. Analisando gráficos de Burndown. InfoQ, 2010.
Mudanças de Sprint. LOCAWEB, 2010.
MAR, Kane. Seven common Sprint Burndown graph signatures. 2006.