Jak wyceniać spady w Scrum?

Życie nie jest usłane różami i nie każda scrumowa iteracja kończy się zrealizowaniem całego Backlogu Sprintu. Te niedokończone wymagania (“spady”) wracają z powrotem do Backlogu. Co się z nimi dzieje później?

Życie ze “spadami”

Przyjęło się, że elementy Backlogu Sprintu, które nie zostały zrealizowane nazywamy “spadami”. Wzięło się to z tego, bo mówi się o nich, że “spadają” na następny Sprint. Ale wcale nie muszą!

Domyślnym działaniem w przypadku niezrealizowania jakiegoś wymagania jest wrzucenie go z powrotem do Backlogu Produktu. Oczywiście, jeśli dopiero co próbowaliśmy je zrealizować, to prawdopodobnie było one jednym z najbardziej istotnych z punktu widzenia Product Ownera. Jest też duża szansa, że to się nie zmieniło. Skoro nadal pozostaje ono priorytetowe, to trafi na kolejną iterację.

Co więcej, rzeczy “prawie zrobione” kuszą swoją atrakcyjnością. Doskonale wiemy, co konkretnie zostało w nich do zrobienia. Zwykle jest to niewiele pracy, z którą można szybko się uporać, aby móc triumfalnie ogłosić podnoszący morale sukces.

Błędy poznawcze, które mogą się przy tej okazji pojawiać to między innymi sunk-cost fallacy oraz Efekt Zeigarnik. Mówiąc krótko: nie chcemy porzucić rzeczy, na którą już poświęciliśmy tyle sił i środków. Co więcej, strasznie nas uwiera fakt, że coś zaczęliśmy i tego nie dokończyliśmy.

Zwykle takie myślenie jest właściwe i potencjalnie utopione koszta faktycznie sprawiają, że warto jest dokończyć pracę. Czasami jednak nasz umysł wyprowadza nas w pole, co szczególnie widać wśród grających na giełdzie. “Tyle w to zainwestowałem, w końcu musi się odbić.” Niestety, nie musi. Tak samo nie zawsze jest sens dokańczać pracę na siłę.

Warto zastanowić się przez chwilę, czy na pewno dane wymaganie nadal jest zasadne. Jeżeli tak, to przemyślmy też, czy na pewno w danej chwili jest to najbardziej istotna rzecz.

Jak wycenić spad?

Planowanie spadu to jedno, ale kwestia jego wyceny to coś, co wielu Project Managerom spędza sen z powiek. Można by rzec, że sami są sobie winni, próbując budżetować Sprinty i przeliczać nasze wyceny na pieniądze, ale taka ich rola. Zastanówmy się więc, w jaki sposób uwzględnić spady chociażby w naszym Velocity.

Prędkość zespołu (Velocity) to średnia liczba punktów realizowanych w poprzednich iteracjach. Jeżeli nagle wydarzy się katastrofa i nie zrealizujemy większości Backlogu Sprintu, to dana iteracja chwilo obniży nam średnią prędkość. “Chwilowo”, bo zwykle te spady zostaną zrealizowane w następnym Sprincie. Ale jak je wycenić?

Przyjmijmy, że wyceniamy wymagania w Story Points. Przeanalizujmy przypadek, gdzie zamiast 20 punktów udało nam się dowieźć jedynie 5. Postanawiamy, że wszystko trafi do Backlogu Produktu, gdzie ponownie wycenimy pracochłonność tego, co zostało do zrobienia.

Ponieważ wyceniamy tylko pozostałą pracę, to wyniesie ona o wiele mniej niż 15 punktów, dla przykładu: 6. Planujemy więc na następny Sprint tyle, ile wynosi nasze Velocity, włączając w to 6 punktów spadów. Nasze historyczne Velocity będzie wyglądało jak na wykresie:

Niby wszystko wygląda dobrze, ale patrząc na cały okres 6 Sprintów, wyparowało nam gdzieś 15 punktów! Licząc średnią prędkość za cały ten czas wyjdzie nam mniej, niż zostało faktycznie dowiezione. Może jest więc inna metoda na wycenę spadów?

A co gdyby spady nie były wyceniane ponownie?

Skoro ponowna wycena spadów powoduje problemy księgowe, to może nie powinniśmy tego robić? Całe 15 niezrealizowanych punktów wrzućmy z powrotem do Backlogu Produktu i ponownie jak w poprzednim przypadku zaplanujmy je na kolejny Sprint.

Niestety, to spowoduje dziwny Sprint, w ramach którego prawie dwukrotnie przekroczymy średnią prędkość naszego zespołu. Oczywiście możemy mieć w pamięci to, że część wymagań to tylko spady, ale musicie przyznać, że wykres dowiezionych punktów wygląda co najmniej dziwnie:

Na szczęście, jeżeli weźmiemy średnią za cały okres, wszystko się zgadza. Praca, którą zespół wykonał w Sprincie 4 jest uwzględniona w wyniku Sprintu 5. Patrząc na poszczególne iteracje wygląda to dziwnie, ale na wartościach średnich jest ok. Warto tylko oznaczyć spady w jakiś sposób, aby ktoś nam kiedyś nie wypomniał, że “były takie Sprinty, gdzie realizowaliście i 39 punktów”.

Wybierając sposób wyceny spadów, należy wziąć pod uwagę, co jest dla nas bardziej bolesne. Jeżeli przeszkadza nam gubienie punktów i zależy nam na poprawnym wyliczaniu prędkości zespołów, wybierzmy drugi sposób. To też jest rekomendacja #białko – nie wyceniajmy ponownie spadów, pogódźmy się z okazyjnym Sprintem, w trakcie którego planujemy się ponad kreskę.

Trzeci sposób wyceny spadów

Czytając powyższe akapity można wpaść na “idealne” rozwiązanie: wyceńmy pracę, która już została zrealizowana i zostawmy ją w poprzednim Sprincie jako “ukończoną”, a resztę zaplanujmy na następny. W taki sposób działają nawet niektóre programy wspierające pracę w Scrum (np. CA Agile Central).

Nie ma chyba gorszych pomysłów. W ten sposób dajemy sobie furtkę do “prawie ukończonych wymagań”. Na Sprinty zaczynamy planować wszystko, co nam przyjdzie do głowy, bo przecież “i tak się podzieli”. Co gorsza, realizując wymagania nie będziemy starali się ich doprowadzić do wdrażalnej i wartościowej dla odbiorcy postaci. Cała idea Przyrostu bierze w łeb.

To pokazuje, jak prawdziwe jest Broken Window Theory, gdzie jeden drobny wyłom w zasadach, może doprowadzić do zawalenia się całej idei.

Nie możemy się godzić na te rozwiązanie, chociaż “księgowo” wypada ono najlepiej. Zamiatamy tutaj pod dywan faktyczne problemy: na Planowaniu Sprintu bierzemy na siebie za dużo wymagań i realizujemy je po łebkach lub tylko częściowo. Cała przewidywalność, którą chwali się Scrum, wyparowuje. W ogóle nie wiadomo o czym świadczy nasza prędkość, ani ile faktycznie jesteśmy w stanie zrobić przez najbliższych kilka iteracji.

Co gorsza, właśnie takie działanie jest źródłem opinii o “niskiej jakości produktów wytwarzanych w scrum”. Trudno żeby było inaczej, jeżeli rezultatem każdego Sprintu są “prawie gotowe” i “być może wdrażalne” funkcjonalności.

Spady nazywajmy spadami i nie udawajmy, że coś zostało zrobione do końca albo chociaż w części. Tak jak nie można być “trochę zdrowym”, tak samo nie można “trochę zrealizować wymagania”. Albo jest ono gotowe do użytku, albo nie. A kontynuując tę analogię: można być po prostu zdrowym albo w świetnej formie. Tak samo nasze wymagania mogą być po prostu gotowe do użycia (“potencjalnie wdrażalne”) albo mogą być najlepsze na świecie, wygodne, ergonomiczne, itd.

Tylko to już wtedy nie jest Minimum Viable Product, który powinien być naszym celem. Szczególnie w sytuacji, w której borykamy się ze spadami.