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.
Não foi possível carregar esta imagem.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).
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
