Prática de aplicação de Burn Down Charts no contexto de SAFe e Scrum

Neste artigo, pretendo contar como, na minha prática, aplicamos o gráfico de queima (Burn Down Chart) no processo de trabalho com a metodologia SAFe

Começarei, talvez, pelo mais interessante. A saber, pelo fato de que o uso desse gráfico no SAFe não deve ter nenhuma especificidade em relação ao uso desse gráfico no SCRUM. Ou deve?

O SAFe, no nosso caso, difere por ter um papel como RTE, diferentemente do SCRUM, onde ele não existe. O Burn Down Chart é uma ferramenta de acompanhamento do volume de trabalho no sprint e é necessário antes de tudo para a equipe SCRUM, e não para alguém de fora, não é mesmo?

Assim, passarei afinal ao modo como usamos o Burn Down Chart, apesar de tudo, e permanecendo ainda dentro do framework SAFe.

Estou no papel de Scrum Master e procuro destacar esse gráfico diariamente para toda a Dev Team. O meio que utilizo é o chat da equipe, menção a toda a equipe via "@", captura de tela do estado atual do gráfico. Mencionar toda a equipe é uma ferramenta bastante delicada e é importante usá-la o mais raramente possível (afinal, nós, Scrum Masters, devemos ajudar a equipe a trabalhar com conforto e com o mínimo possível de desfoque, não é mesmo?)

No fim, a equipe vê diariamente o estado atual do sprint e é capaz de acompanhar os seguintes eventos

• Surgimento de trabalho não planejado
• Longa permanência de tarefas em status não concluído
• Excesso de riscos embutidos
• Entendimento — se o trabalho está no ritmo correto

A seguir, tentarei detalhar cada um desses eventos e trazer exemplos da minha prática.

Surgimento de trabalho não planejado

Neste gráfico, vê-se muito bem como surge um novo trabalho (na segunda terça-feira do sprint de duas semanas).

Caso da prática: "O desenvolvedor, como membro da equipe scrum, que compartilha os princípios agile, interage muito bem com o Product diretamente. O Product diz a ele que isto precisa ser implementado rapidinho, você mesmo entende, aqui é rápido e os riscos são mínimos.

O desenvolvedor é ótimo, ele sabe tudo sobre agile e sobre a importância da entrega de valor de negócio, vai e joga no quadro uma história do backlog, avaliada pela equipe em 6 sp.

O restante da equipe (exceto o desenvolvedor e o Product) percebe isso na atualização matinal do gráfico. No standup, a equipe toma a decisão de como lidar com essa situação. Muito provavelmente, a história é retirada do sprint, e a equipe deixa claro para o Product e o Desenvolvedor que não se pode fazer assim, e o product pode colocar essa história no próximo sprint, se necessário.

Claro que, no ideal, a equipe deveria perceber o surgimento de novo trabalho no standup e sem o gráfico. Mas o gráfico é um bom indicador, que reduz ao mínimo os riscos de não perceber essa mudança tão importante para toda a equipe.

Aqui é importante entender que o cenário poderia ter seguido caminhos diferentes dependendo do nível da equipe. Em equipes excelentes, o Product Owner dificilmente faria assim, e, se fizesse, argumentaria não com o fato de que «isto pode ser implementado rapidinho», mas com o fato de que «eu estimo em 55% a probabilidade de que, se isto for implementado agora, possa aumentar nosso lucro em 20% no próximo mês» ou com alguma outra métrica mensurável.

Longa permanência de tarefas em status não concluído

Aqui vemos que, por muito tempo, o trabalho não é concluído nem mesmo parcialmente. Isso pode sinalizar diferentes problemas, listarei alguns deles

• Decomposição ruim das tarefas

  Muitas vezes, equipes iniciantes falam sobre a impossibilidade de decomposição. Nelas tudo queima no último dia, o trabalho não é paralelizado etc. Claro, é necessário trabalhar isso com o Scrum Master e explicar o valor da decomposição para a equipe.

• DOD não formulado de forma otimizada

  DOD (Definition of Done) - descrição dos critérios de prontidão da User Story na sprint. Às vezes eles simplesmente não existem ou são descritos de forma muito abstrata. Isso bem pode ser um problema que, naturalmente, o Scrum Master deve ajudar a resolver

Excesso de provisionamento de riscos

Neste caso, vemos uma situação em que a equipe provisionou riscos em excesso.

Possivelmente, alguma história foi superestimada. Possivelmente, é um problema mais sistêmico e é necessário aumentar o volume de trabalho no planejamento da sprint. Em qualquer caso, esta situação não é correta. Afinal, o negócio planejava que seriam realizadas justamente as tarefas da sprint e justamente até o final da sprint. Dependendo de como as dependências foram planejadas, aqui provavelmente será necessário realizar reuniões para ajustar as expectativas.

Na minha prática, isso aconteceu quando se encontrou uma solução mais rápida do que a discutida na estimativa. Discutimos com toda a equipe qual história conseguiríamos fechar até o final da sprint e na retrospectiva combinamos que tentaríamos olhar o código durante o grooming. Descobriu-se que bastava simplesmente olhar o código para entender que a solução era bem mais simples.

Entendimento - se o trabalho está no ritmo correto

Aqui eu gostaria de chamar a atenção para formas graficamente malsucedidas de exibir o Burn Down Chart

Na parte superior da imagem é apresentado um exemplo de implementação gráfica não muito bem-sucedida por duas razões, que exporei abaixo.

• Não é perceptível a entrada de novos SP na sprint

  Aqui, no diagrama superior, praticamente não se percebe que foi adicionado trabalho não planejado. No inferior, isso é mais evidente.

• O restante relativo de trabalho é exibido de forma incorreta

  De acordo com o diagrama superior, ainda restavam 3 dias de trabalho. Na verdade, são 2, no dia de folga, possivelmente, alguém planeja descansar.

Claro, para alguns tais detalhes podem parecer insignificantes. Mas é preciso entender que cada membro da equipe apenas dará uma olhada de relance nesse diagrama e ele deve transmitir o máximo de informação útil.