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:

Velocity w przypadku przeliczania spadów

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:

Velocity bez przeliczania spadów

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.

Tomasz Dzierżek

16 lat doświadczenia w IT, 8 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Mateusz Żeromski - 22 stycznia 2019

Cześć

Brak ponownej wyceny “spadów” może powodować regularność takich zdarzeń.
Znikające punkty są silną mobilizacją do
1. Lepszego doskonalenia zadań, rozbijania na mniejsze
2. Realizacji w 100% (pamiętajmy o testowaniu przed Done)
3. Jeżeli wiemy, że nie damy rady zrealizować wszystkich zadań – skupimy się na “wykończeniu” kilku na 100%, a inne zrealizować na 0% – tak aby nie było znikających punktów.

Ponowna wycena uczy też pokory bo widać poszarpane velocity.
Dziwne velocity nie powinno być problemem dla zespołu – bo oni wiedzą co i dlaczego.

W sytuacji gdy nie ma ponownej estymacji
1. Tworzymy okazjonalne Sprinty co mogą przestać być okazjonalne, słowo może być źle zrozumiane,
1a. Trzeba naprawdę silnego charakteru aby nie powstały okazjonalne spriny non stop
2. Bierzemy pod uwagę aspekty które powinny być poza obszarem zainteresowania – przeliczania punktów na kasę i budżet
3. Velocity – to tylko wykres dla zespołu DEV

Podsumowując, z PM jest zawsze problem, ale to już rola SM aby wytłumaczyć, że poszarpany wykres jest na + bo bardziej uczy aniżeli kreatywna księgowość 🙂

Reply
    Tomasz Dzierżek - 22 stycznia 2019

    Kwestia sposobu wyceny wydaje mi się kompletnie niezależna w stosunku do regularności takich zdarzeń. Zgadzam się też, że to już odpowiedzialność PM-a, żeby przełożyć dane dostępne w backlogach na potrzebne mu miary (np. pieniądze). Poszarpany wykres może być jednak kłopotem dla Product Ownera, który mając kilka zespołów realizujących jeden Product Backlog będzie miał problemy z oszacowaniem terminów ukończenia poszczególnych funkcjonalności.

    Reply
Pawel - 4 sierpnia 2019

oczywiście, ze nie powinnismy wyceniać spadów ponownie 😊 przecież ich zlozonosc i ilość pracy, która musimy w nie włożyć nie mogła się zmienić skoro wymagania dotyczące funkcjonalności się nie zmieniły. Sytuacja spadków to anomalia i musimy ja przełknąć. Powiedziałbym nawet, ze ma kłuć w oczy. Świadczy tylko i wyłącznie o jakimś problemie czy to przy planowaniu pracy, definiowaniu wymagań, podziale na mniejsze zadania…. W następnym sprincie to po prostu farba poprawić 😊

Reply
Leave a Reply: