← Eseje

Praktyka stosowania Cumulative Flow w kontekście Scrum i SAFe

W tym artykule planuję opowiedzieć, jak w naszej praktyce stosujemy Cumulative Flow Chart w Scrum w procesie pracy według frameworka SAFeBlog osobisty.

2 min czytania
Praktyka stosowania Cumulative Flow w kontekście Scrum i SAFe

W tym artykule planuję opowiedzieć, jak w naszej praktyce stosujemy Cumulative Flow Chart w Scrum w procesie pracy według frameworka SAFe

Zacznę chyba od linku do takiego artykułu - tutaj, moim zdaniem, dobrze opisano jego przeznaczenie w standardowej postaci, polecam zapoznać się przed przeczytaniem mojego artykułu. Poniżej opiszę, jak go zaadaptowaliśmy do procesu Scrum (pierwotnie jest używany w Kanban) i jakie problemy pomaga nam rozwiązywać podczas pracy w sprintach.

Wcześniej, w artykule o Burn Down Charts mówiłem już, że widzimy tam pojawianie się nowej pracy i wypalanie starej. Problem Burn Down Chart polega na tym, że w przeciwieństwie do Cumulative Flow Chart nie widzimy na niej ruchu Historyjek Użytkownika po statusach. Kiedy natomiast zaczynamy obserwować ruchy po statusach w Cumulative Flow Chart, zaczynamy widzieć codzienne zmiany (Burn Down Chart może się nie zmieniać przez kilka dni i w niektórych kontekstach może to być całkiem normalne) i możemy zauważyć subtelniejsze problemy.

Oto jak to może wyglądać w dynamice (na obrazku diagram zbudowany na rzeczywistych danych).

Image



Image

W tym przykładzie widzimy następujące rzeczy

  • Przez pierwsze 7 dni sprintu w testowaniu znajduje się bardzo mały wolumen pracy i nie zmienia się
  • Z DOR (tutaj to szkic) do pracy Historyjki Użytkownika przechodzą dość równomiernie - to dobrze.
  • Podobnie jak na Burn Down, widzimy, że zgodnie z tendencją Historyjki Użytkownika nie zostaną ukończone do końca sprintu

Te 3 obserwacje razem prowadzą do następującego wniosku. Tutaj wyraźnie już na wczesnych etapach (gdzieś w drugim-trzecim dniu sprintu) Scrum Master powinien był zwrócić uwagę na warstwę "Testowanie", która jest zbyt mała i nie zmienia się wystarczająco długo (ustalić, jaka jest przyczyna). Można przypuszczać, że wolumenu pracy gotowej do testowania nie da się przetestować z jakichś powodów, ale wtedy oznacza to, że testerzy stoją bezczynnie, a więc przynajmniej warto uważniej ich wysłuchać na najbliższym standupie.

Jeśli mówić o praktyce stosowania, to ja na przykład codziennie publikuję w czacie zespołu wszystkie metryki przed standupem, z oznaczeniem całego zespołu.

Ogólnie nie należy zapominać, że metryki trzeba jednak właściwie interpretować. Umieć dostrzegać rzeczywiście problemy systemowe, jeśli takie są, i nie uznawać za problemy tego, co w waszym kontekście może być nawet pozytywnym sygnałem