← Ensaios

Prática de uso do Cumulative Flow no contexto de Scrum e SAFe

Neste artigo, pretendo contar como, na nossa prática, aplicamos o Cumulative Flow Chart no Scrum durante o processo de trabalho com o framework SAFeBlog pessoal.

2 min de leitura
TelegramOriginal
Prática de uso do Cumulative Flow no contexto de Scrum e SAFe

Neste artigo, pretendo contar como, na nossa prática, aplicamos o Cumulative Flow Chart no Scrum durante o processo de trabalho com o framework SAFe

Vou começar, talvez, com um link para este artigo - aqui, na minha opinião, está bem descrita a sua finalidade no formato padrão; recomendo estudá-lo antes de ler o meu artigo. Abaixo, descreverei como o adaptamos para o processo Scrum (originalmente ele é usado no Kanban) e quais problemas ele nos ajuda a resolver ao trabalhar por sprints.

Anteriormente, no artigo sobre Burn Down Charts eu já disse que ali vemos o surgimento de novo trabalho e a queima do antigo. O problema do Burn Down Chart é que, diferentemente do Cumulative Flow Chart, nele não vemos o movimento das User Stories pelos status. Quando começamos a observar os movimentos pelos status no Cumulative Flow Chart, começamos a ver as mudanças diárias (o Burn Down Chart pode não mudar por vários dias e, em alguns contextos, isso pode ser perfeitamente normal) e podemos notar problemas mais sutis.

É assim que isso pode parecer em dinâmica (na imagem, um gráfico construído com dados reais).

Image



Image

Neste exemplo, vemos o seguinte

  • Nos primeiros 7 dias do sprint, há um volume muito pequeno de trabalho em teste e ele não muda
  • Do DOR (aqui é o rascunho) para o trabalho, as User Stories saem de forma bastante uniforme - isso é bom.
  • Assim como no Burn Down, vemos que, segundo a tendência, as User Stories não serão concluídas até o final do sprint

Essas 3 observações em conjunto levam à seguinte conclusão. Aqui, claramente, ainda nos estágios iniciais (por volta do segundo ou terceiro dia do sprint), o Scrum Master deveria ter chamado a atenção para a camada "Teste", que é pequena demais e não muda por tempo suficiente (verificar qual é o motivo). Pode-se supor que o volume de trabalho pronto para teste não pode ser testado por alguma circunstância, mas então isso significa que os testadores estão ociosos e, portanto, no mínimo, vale a pena ouvi-los com mais atenção no próximo standup.

Falando da prática de uso, eu, por exemplo, publico diariamente no chat da equipe todas as métricas antes do standup, mencionando toda a equipe.

Em geral, não se deve esquecer que, afinal, as métricas precisam ser interpretadas corretamente. Saber ver problemas realmente sistêmicos, se existirem, e não considerar como problemas aquilo que, no seu contexto, pode ser até um sinal positivo