Blog

Nawiązując do  wcześniejszego wpisu 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óż przy pełnym zrozumieniu czym jest velocity okazało się, że nie do końca jest jasne co zrobić, jeśli zespół rozpoczął realizację wymagania, ale nie zdołał wykonać wszystkich niezbędnych prac przed końcem sprintu i Definition of Done lub kryteria akceptacyjne nie zostały spełnione.

Przykład: zespół zaplanował, że w sprincie poza innymi wymaganiami zrobi też jedno, które wyszacował na 13 story pointów. Wszystkie pozostałe udało się skończyć, tego jednego nie. Zespół szacuje, że zostało „około 3 story pointy” do zrobienia. Nie da się podzielić wymagania tak, żeby to, co zostało do zrobienia, skończyć w innym sprincie a to, co już zostało zrobione, uznać za gotowe do wydania. Co teraz?

Co zrobić z wymaganiem

Wraca do backlogu, to dość oczywiste. Ponieważ backlog produktu opisuje wszystko, co powinno być zrealizowane w produkcie (wymagania, potrzeby, czasami zmiany wynikające z konieczności rozwiązania błędów), takie częściowo zrealizowane wymaganie musi wylądować w backlogu.

Pierwsza trudność: na jakiej pozycji? Wydawać by się mogło, że skoro już nad nim pracujemy, na samej górze. Pamiętać jednak należy, że w czasie sprintu w backlogu produktu pojawiają się nowe wymagania, które – nierzadko – mogą być ważniejsze niż te, nad którymi zespół już pracuje lub pracował. To, że Product Owner nie zdecydował się na przerwanie sprintu i podjęcie realizacji tych nowych wymagań wcale nie oznacza, że nie są one ważniejsze (pilniejsze, bardziej wartościowe – jakkolwiek to nazwiemy) niż to, czego nie udało się skończyć.

Dlatego nie powinniśmy zakładać, że wymaganie będzie kontynuowane w kolejnym sprincie. Ba, nie powinniśmy zakładać, że będzie kontynuowane w ogóle. Może z faktu, że nie udało się go skończyć wyniknie decyzja Product Ownera, że nie warto dalej inwestować czasu i wysiłku w prace nad nim? Dlatego to Product Owner decyduje, co dalej.

Trudność druga: czy wymaganie powinno zostać zmienione w jakiś sposób? Oczywiście tak. Po co? Aby czytelnie opisywało to, co jest wciąż do zrobienia. Pamiętajmy, że coś już zostało wykonane, więc cel biznesowy być może jest taki sam, ale niekoniecznie pracy pozostałej do zrobienia zawsze jest tyle samo. Zazwyczaj nie zmieniamy samej definicji wymagania ani kryteriów akceptacyjnych w takim przypadku, ale zmieniamy… no właśnie – szacunek pracochłonności. Gdzieś w wymaganiu odnotowujemy, że prace już częściowo wykonaliśmy, a więc do zrobienia jest mniej, niż na początku.

A zatem szacunek 13 story pointów jest już zbyt wysoki. Dokonujemy więc ponownego wyszacowania tego, co jest wciąż „do zrobienia” i wychodzi z tego na przykład owe wspominane przez zespół 3 story pointy.

Velocity w zakończonym sprincie

Pytanie, jak policzyć velocity w tym właśnie zakończonym sprincie. Bo praca o wartości 10 story pointów została wykonana, wydaje się więc uczciwe by dodać te 10 story pointów do velocity. Choć to kuszące, nie powinniśmy tego robić. Skoro wymaganie nie zostało zrealizowane, czyli DoD dla niego nie zostało spełnione, z punktu widzenia prędkości realizacji wymagań to wymaganie (częściowo zrobione) nic nie wnosi. A zatem w tym sprincie 10 story pointów „przepada”.

Velocity w sprincie, w którym dokończymy wymaganie

Skoro wymaganie po jego zwróceniu do backlogu produktu zostało przeszacowane i ma teraz wartość 3 story pointów, gdy w którymś z przyszłych sprintów je dokończymy, do velocity tego sprintu dodamy… dokładnie tak, 3 story pointy. Co oznacza, że owe 10 story pointów wcześniej wykonanej pracy nie zostanie w żaden sposób „odzyskane”. I uczciwie mówiąc nie powinno zostać, albowiem nie była to skończona praca, nie było w niej wartości dla biznesu. Jak zatem moglibyśmy uwzględniać tą pracę w prędkości realizacji wymagań biznesowych?

Z dokładnie tych samych przyczyn nie przypisujemy oszacowań do błędów (bo praca nad nimi to rozwiązywanie problemu, który sami wprowadziliśmy, a nie rozwój oprogramowania).

A gdyby tak nie zmieniać oszacowania, bo…

…przecież statystyka nam tu pomoże. Nie zmieniajmy tych 13 story pointów na 3. Skończymy to wymaganie w którymś z kolejnych sprintów, a jak się to uda, dodamy sobie w nim do velocity pełne 13 story pointów. Tak, przekłamiemy prędkość w tym przyszłym sprincie, ale statystycznie średnia z obu sprintów w których realizowane było to wymaganie pokaże nam, że…

Stop! Scrum jest metodą opartą o empiryzm, a to wymaga przejrzystości. Jeśli posługujemy się konceptem velocity to w każdym sprincie powinno ono pokazywać dokładnie to, co w tym sprincie udało się skończyć. Rzeczywiście, nie „statystycznie”. O ile podejście jest kuszące, wiedzie na manowce.

Poza oddalaniem się od empirycznej kontroli procesu problemem jest taka kwestia: jak zaczniemy na velocity patrzeć „statystycznie” w ujęciu wielu sprintów, ta średnia może na przykład wynieść 30 story pointów, a w praktyce być dużo niższa. Jeśli pierwszy sprint zakładał realizację wymagań o sumie szacunków 45 story pointów, drugi tak samo, ale dopiero w trzeciej iteracji udało się je ukończyć, to jeśli nie zredukujemy estymat, średnia z trzech sprintów wygląda dobrze. „Statystycznie” pracujemy ze stabilną, całkiem niezłą prędkością 30 story pointów. Rzeczywistość wygląda jednak dużo gorzej: większość sprintów nie dostarcza nic, a trzeci też niewiele (bo tylko kończymy coś już wcześniej zaczętego).

Dlatego nie bawmy się w statystykę, dążmy do przejrzystości – patrzmy na rzeczy takie, jakimi one są naprawdę.

Kto używa wartości średnich velocity?

Product Owner – do projekcji przyszłych wydań, tak jak opisałem we wspomnianym już wcześniej wpisie. Zauważmy jednak, że i on wolałby, aby te projekcje robić w oparciu o rzeczywiste velocity, a nie jego „statystyczne” modelowanie. Skoro sam proces projekcji wydań i planowania ich dat jest obłożony błędem wynikającym z niepewności estymat i braku gwarancji, że velocity uda się utrzymać, uczynienie z velocity kolejnego szacunku zamiast rzeczywistego pomiaru czyni plany Product Ownera bardziej podatnymi na błędy.