Blog

Nawiązując do  wcześniejszego artykułu o velocity, chciałbym odpowiedzieć na pewną wątpliwość, która pojawiła się w jednym z Zespołów, który wspieram jako Agile coach. Otóż Zespół zaplanował, że w Sprincie zrealizuje kilka wymagań, w tym między innymi jedno wyszacowane na 13 story pointów. Wszystkie wymagania z wyjątkiem tego jednego udało się ukończyć. Developerzy oceniają, że zostało w nim pracy na „około 3 story pointy” i w żaden sposób nie da się podzielić wymagania na to, co udało się skończyć i resztę, jaka wciąż jest do zrobienia. Co teraz powinno się stać i w jaki sposób wyliczyć prędkość Zespołu?

Co zrobić z wymaganiem?

O tym zdecydować musi Product Owner, to dość oczywiste. Opcje ma w praktyce dwie:

• zrezygnować z ukończenia prac, czyli wywalić wymaganie do kosza wraz z całą pracą, jaką do tej pory wykonali w jego kontekście Developerzy,
• umieścić w Backlogu Produktu, jeśli rozwiązanie opisane tym wymaganiem wciąż jest potrzebne.

Wydawać by się mogło, że istnieje i trzecia opcja, jaką byłoby po prostu pozostawienie wymagania w Backlogu Sprintu, aby prace kontynuowane były w kolejnej iteracji. W rzeczywistości taka decyzja jest tożsama z pierwszą opcją, czyli wywaleniem wymagania do kosza. Dlaczego?

Backlog Sprintu tworzony jest dopiero w trakcie Planowania Sprintu. Developerzy nie posługują się więc w szeregu Sprintów jednym i tym samym Backlogiem Sprintu, tylko na potrzeby każdej iteracji tworzony jest zupełnie nowy Backlog Sprintu opisujący to, co Zespół zamierza w niej osiągnąć.

Gdy w momencie zakończenia Sprintu cokolwiek wciąż pozostaje w Backlogu Sprintu jako rzecz do zrobienia, nie staje się automatycznie częścią Backlogu Sprintu iteracji kolejnej. Po prostu zostaje sobie tam, gdzie jest i nic się z tym nie dzieje, bo iteracja, z którą ten Backlog Sprintu jest związany, już się zakończyła.

Jeśli Product Owner ma intencję kontynuowania prac nad nieukończonym wymaganiem, nie może przerzucić go wprost do Backlogu Sprintu kolejnego z czterech powodów:

1. Backlog Sprintu kolejnego jeszcze nie powstał (Developerzy stworzą go dopiero w trakcie Planowania Sprintu), więc ciężko w nim cokolwiek umieścić.
2. Backlogiem Sprintu zarządzają Developerzy, a nie Product Owner, więc nic nie może im tam umieścić bez łamania zasad Scruma.
3. Decyzję o tym, co będzie realizowane w Sprincie, podejmuje cały Zespół Scrum w trakcie Planowania Sprintu, a nie samodzielnie Product Owner jeszcze przed rozpoczęciem iteracji.
4. Artefaktem, którego Product Owner używa, aby przedstawić swe plany rozwoju produktu, jest Backlog Produktu, a nie Backlog Sprintu.

Wróćmy do przykładowej sytuacji i przyjmijmy, że Product Owner uznał za sensowne kontynuowanie prac nad nieukończonym wymaganiem. Musi umieścić je w Backlogu Produktu. Na jakiej pozycji? Być może na samej górze, skoro Developerzy już zaczęli realizację tego wymagania. Pamiętać jednak należy, że w czasie Sprintu w Backlogu Produktu pojawiają się nowe wymagania. Niektóre z nich mogą być naprawdę pilne, choć nie aż tak palące, by Product Owner zdecydował się ze względu na konieczność rozpoczęcia prac nad nimi przerwać toczący się już Sprint. Zdecydowanie jednak pilniejsze niż dokończenie prac nad częściowo zrealizowanymi wymaganiami.

Dlatego pozycja, na której umieszczone w Backlogu Produktu zostanie takie nieukończone wymaganie, zależy w pełni od decyzji Product Ownera. Nie ma żadnej zasady, która nakazywałaby umieścić je na szczycie – równie dobrze może to być sam koniec listy elementów.

Gdy już Product Owner zdecyduje, gdzie umieścić nieukończone wymaganie, pojawia się kolejne pytanie: czy powinno ono zostać w jakiś sposób zmienione, czy też raczej należy pozostawić go w oryginalnej formie?

Oczywiście, że powinno zostać zmienione tak, by odzwierciedlić to, co pozostało do zrobienia. Umieszczenie w Backlogu Produktu częściowo zrealizowanego wymagania bez aktualizacji jego opisu spowoduje spadek przejrzystości Backlogu Produktu. Opis nie będzie odzwierciedlał tego, co faktycznie jest do zrobienia, tylko jakiś historyczny, już nieistniejący stan spraw.

To samo dotyczy ewentualnego oszacowania tego wymagania (jego wielkości, pracochłonności, czasochłonności, wielkości itd.). Jest mało prawdopodobne, że oryginalna estymata pasuje do tego, co pozostało do zrobienia. Należy ją sprawdzić i ewentualnie skorygować albo przynajmniej usunąć, żeby nie wprowadzała w błąd.

Jak to wygląda dla przykładowego wymagania, którego nie udało się ukończyć? Oryginalnie zostało wyszacowane na 13 punktów, ale w ocenie Developerów pozostała praca to odpowiednik zaledwie trzech story pointów. I taka powinna być teraz estymata tego wymagania widoczna w Backlogu Produktu.

Velocity w kończącym się właśnie Sprincie

Pytanie, jak policzyć velocity w tym właśnie zakończonym Sprincie? Uwzględniona w nim zostanie na pewno suma oszacowań wszystkich wymagań, które ukończone zostały. A co z tym nieukończonym, które powróciło do Backlogu Produktu? Praca o wartości 10 story pointów została wykonana, wydaje się więc uczciwe, by dodać owe 10 story pointów do velocity. Choć to kuszące, nie powinniśmy tak robić. Dlaczego?

Prędkość, jak sama nazwa wskazuje, jest tempem, z jakim Zespół przesuwa się w dół listy elementów Backlogu Produktu (tempem zjadania lub spalania tego Backlogu). Nie jest miarą produktywności czy ilości wykonanej pracy. Przykładowo, jeśliby Zespół realizował 20 wymagań, a na koniec Sprintu każde z nich byłoby „gotowe na 99%”, to mimo ciężkiej pracy Developerów wszystko wciąż pozostawałoby do zrobienia. Prędkość w takim Sprincie w oczywisty sposób byłaby zerowa.

I dokładnie ta sama zasada obowiązuje w mniej skrajnym, ale bardziej typowym przypadku, gdy nie uda się ukończyć prac nad jednym wymaganiem. A zatem do velocity Sprintu nie można dodać ani 13 story pointów, ani nawet 10 story pointów. Można powiedzieć, że ciężka praca Developerów nie przełożyła się w tym przypadku na zwiększenie prędkości.

Warto przy okazji wspomnieć, że tak samo należałoby liczyć velocity również wtedy, gdyby Product Owner nie zdecydował się na kontynuowanie prac nad wymaganiem. Ktoś może teraz zaprotestować, że skoro nie wraca ono wtedy do Backlogu Produktu, to ubyło w nim elementów i prędkość jest niezerowa! Problem w tym, że velocity nie jest miarą tempa zmniejszania się Backlogu, ale tempa realizacji tego, co jest w nim zawarte. Porzucenie niedokończonych wymagań nie dodaje więc nic do prędkości.

Velocity w Sprincie, w którym dokończone zostanie wymaganie

Skoro wymaganie po jego zwróceniu do Backlogu Produktu zostało ponownie wyszacowane i ma teraz wielkość 3 story pointów, gdy w którymś z przyszłych Sprintów Zespół je dokończy, do velocity tego Sprintu dodać będzie mógł dokładnie 3 story pointy. Co oznacza, że owe 10 story pointów wcześniej wykonanej pracy nie zostanie w żaden sposób odzyskane. Przepadło?

Tak, przepadło. Praca została wykonana, ale nie przełożyła się na żadną wartość dla interesariuszy i konieczna była dogrywka. I dopiero wtedy pojawiła się wartość. Jeśli Developerzy uznają, że to niesprawiedliwe, bo zaboli ich „strata story pointów” to nawet dobrze. Być może dzięki temu zaczną dążyć do tego, by taka sytuacja się nie powtórzyła.

Zaufajmy statystyce?

Ktoś powie: nie ma sensu bawić się w zmiany oszacowań, bo na przestrzeni kilku Sprintów statystyka zadziała i pokaże nam realną prędkość, z jaką pracujemy. Natomiast przeszacowując wymagania w sposób opisany powyżej, zaniżamy tę średnią prędkość!

Faktycznie, to kuszący argument, bo niezaprzeczalnie tak właśnie jest. Gubiąc część story pointów na skutek zmian oszacowań (o ile zmieniać się one będą w dół, a nie w górę), obniżymy średnią prędkość wyliczaną z szeregu Sprintów. Można nawet policzyć, odwołując się do oryginalnych estymat, jak duża jest to różnica.

Problem w tym, że celem Zespołu Scrum nie jest generowanie takiej czy innej wartości velocity, ani nawet produktywność, ale skuteczne dostarczanie wartości w procesie na tyle przewidywalnym, żeby dało się realnie z tej wartości korzystać. Gdy funkcjonuje się w złożonym środowisku o dużej zmienności i nieprzewidywalności, niezbędne jest kontrolowanie procesu w sposób empiryczny – na bazie faktów, niekoniecznie zaś na bazie dobrze wyglądających wartości średnich różnych parametrów.

Człowiek idący na spacer z psem ma statystycznie trzy nogi, podobnie jak prowadzony przez niego pupil. Przy czym statystyczna liczba nóg niewiele ma wspólnego z ich liczbą faktyczną: człowiek nadal ma nogi dwie, a pies niezmiennie pozostaje czworonogiem. Podobnie zwodnicze jest przywiązywanie dużej wagi do średniej prędkości wyliczonej z wielu Sprintów.

Wyobraźmy sobie Zespół, który w większości Sprintów niczego nie potrafi ukończyć i zawsze potrzebuje kontynuować prace przez dwie albo trzy kolejne iteracje, aż wreszcie uda mu się zbudować coś działającego. Jeśli Zespół ten nie będzie dokonywał przeszacowań niedokończonych wymagań w sposób, o jakim pisałem powyżej, jego velocity wyliczone dla szeregu Sprintów będzie naprawdę niezłe – a dokładniej takie samo, jak gdyby udawało się w każdej iteracji zrobić wszystko, co podjęte zostało do realizacji w niej. Dopiero patrząc jednostkowo na każdy Sprint, zobaczymy, że prędkość w większości z nich jest niemal zerowa, a co jakiś czas pojawia się ekstremalna (nierealnie wysoka) wartość.

Statystycznie praca takiego Zespołu wygląda całkiem nieźle, choć w rzeczywistości realnego sprawdzenia, czego warty jest produkt, da się dokonać tylko co któryś Sprint, a proces jest kompletnie niestabilny i nieprzewidywalny. Co więcej, użycie wiedzy o tak wyliczanym velocity do sporządzenia prognoz może spowodować produktową katastrofę, bo statystycznie w każdym Sprincie dostarczane jest mniej więcej tyle samo rzeczy, podczas gdy faktycznie dzieje się to sporadycznie. Jak wytłumaczyć interesariuszom, że Zespół nie wyrobił się z czymś na czas, choć ma świetną średnią prędkość, bo trafiło akurat na ten „gorszy Sprint”, w którym velocity rzeczywiste wynosiło zero?

Zupełnie inaczej będzie wyglądać sytuacja tego Zespołu, gdyby dokonywał on zmiany oszacowań nieukończonych wymagań. Jego velocity w będzie w większości Sprintów bardzo niskie lub zerowe, a w niewielu co najwyżej przyzwoite. Średnia wartość velocity będzie jednakże bardzo niska – ujawniając problem, jaki Zespół ma z realizowaniem czegokolwiek w czasie jednego Sprintu. Również prognozy sporządzane na bazie tak wyliczonej prędkości nie będą nigdy optymistycznie obiecywać, że będzie dobrze – będą raczej pokazywać, jak bardzo źle jest.

Jak definiuje to Scrum?

Nie definiuje wcale. Scrum Guide nie nakazuje żadnej formy szacowania elementów Backlogu Produktu ani nie wzmiankuje w ogóle velocity. Wszystko to są praktyki skojarzone ze Scrumem, po które Zespoły mogą sięgnąć, jeśli uznają je za potrzebne.

Dlatego w zasadzie dowolny sposób podejścia do szacowania i wyliczania velocity jest w Scrumie dopuszczalny. Co nie znaczy, że każdy z nich będzie sensowny. Starałem się pokazać możliwe pułapki, ale to odpowiedzialnością Zespołów (i ich Scrum Masterów) jest dbanie o to, by w nie nie wpaść.