Zdarza się, że niektóre elementy Rejestru Produktu realizowane przez Zespół Scrumowy w Sprincie nie są ukończone w całości (patrząc z perspektywy Definicji Ukończenia czy kryteriów akceptacji). Jeśli Zespół estymuje i podchodzi do estymat sumiennie, pojawia się w takim przypadku poważne pytanie – czy na koniec Sprintu częściowo wykonane zadanie oszacować ponownie (reestymować, odświeżyć jego oszacowanie). Tego typu pytania ostatnio ponownie trafiły mi się w trakcie wspierania zespołów, a temat jest na tyle rozbudowany, że postanowiłem zebrać możliwe niuanse tej sytuacji w osobny artykuł.
W temacie reestymowania nieukończonych zadań widuję najpopularniejsze trzy podejścia, które zebrałem w poniższej tabeli:
| Nazwa podejścia | Przykład | Definicja |
|---|---|---|
| Oszacuj pracę pozostałą do wykonania | Do Sprintu wzięliśmy historyjkę o 13 story pointach, wykonaliśmy jej część, szacujemy że praca jaka pozostała do wykonania to 5 story pointów i tę wartość przyjmujemy jako oszacowanie w Rejestrze Produktu (Product Backlog),a do poprzedniego sprintu nie zaliczamy żadnych Story Pointów | Na podstawie nowej informacji, jaką masz dzięki zrealizowaniu prac w poprzednim Sprincie, podaj aktualną wycenę „ile jeszcze potrzeba pracy, by wykonać dane zadanie” |
| Reestymuj do nowej wyceny całości zadania | Do Sprintu wzięliśmy historyjkę o 13 story pointach, trochę nad nią popracowaliśmy ale nie udało nam się zrobić jej całej. Po wykonaniu części pracy jesteśmy w stanie podać lepszy szacunek, oceniamy ją w całości na 21 story pointów i taką wartość wpisujemy do Rejestru Produktu | Zakładasz, że wiesz już o zadaniu więcej, bo część pracy jest już wykonana, więc podaj nową wycenę całości zadania (włącznie z częścią wykonaną). Być może wycena będzie niezmieniona, a być może odkryjemy jakieś nowy fakty i ją zwiększymy albo zmniejszymy |
| Nie reestymuj, pozostaw starą wycenę | Historyjka była oceniona na 13 story pointów, nie udało się jej zrobić całej, w którymś z kolejnym Sprintów będzie realizowana nadal jako 13 story pointów niezależnie od ilości pracy już wykonanej ani nowych informacji, jakie o pracy do wykonania odkryliśmy | Trzymaj się twardo starej wyceny, przenieś ją na nowy Sprint nietkniętą, nie przejmuj się jej wycenianiem na nowo w kolejnej iteracji, złożoność zadania do wykonania jest już ustalona przez zespół przed poprzednim Sprintem i nie wnikamy w nią nawet jeśli w toku wykonywania pracy pojawią się wątpliwości co do wielkości historyjki |
Każde z tych podejść ma swoje argumenty za i przeciw, a niejeden zespół spędził upojne godziny na Retrospektywach Sprintu, dyskutując które z nich jest lepsze. Przede wszystkim warto trzymać się konsekwentnie jednej strategii – nie mieszać różnych podejść w ramach tego samego zespołu, ponieważ utrudni to w znacznym stopniu możliwość prognozowania prac. Zdecydowanie odradzam z doświadczenia taktykę „splitowania” (niektóre narzędzia wręcz wprost to umożliwiają) – robiliśmy historyjkę za 13 SP, “zrobiliśmy” jej większą część, więc klonujemy zadanie, w starym Sprincie “zaliczamy” sobie 8 SP jako zrealizowane, a zadanie na dokończenie o wartości 5 bierzemy do nowego Sprintu. To jest naruszanie Definicji Ukończenia, oszukiwanie się co do faktycznej prędkości i przyzwyczajanie zespołu do tego, że nie trzeba dobrze przygotować elementu backlogu na etapie Refinementu, ani dzielić go na mniejsze elementy, tylko wystarczy odrobina kombinowania w narzędziu na koniec Sprintu.
Ja sam prywatnie jestem fanem podejścia pierwszego – reestymuj pracę, jaka pozostała do wykonania w danym zadaniu i „nadpisz” starą wycenę (najczęściej pewnie obniż). Jeśli zadanie przeszło między Sprintami, to w poprzednim Sprincie jest zerowe wykonanie, ale w aktualnym, w którym zadanie ostatecznie zostanie zrealizowane, wyceniamy tylko to, co jest nadal do zrobienia (czyli najczęściej w pewnym sensie umykają z naszego velocity punkty, które już częściowo zrobiliśmy). To jest podejście trochę surowe dla zespołu (a niektórzy powiedzieliby – niesprawiedliwe), bo ta nieukończona praca znika z niektórych raportów. Ja sam właśnie dlatego je preferuję – niekończenie planowanej pracy ma boleć, mamy się zastanowić jak to zrobić, żeby w każdym Sprincie uzyskiwać Przyrost i realizować Cel Sprintu. Korzyścią takiego podejścia jest też unikanie zjawiska pompowania wyników prędkości Sprintu, w którym domknęliśmy “spady” z poprzedniego – pobieżne analizowanie takiego Sprintu może niebezpiecznie sugerować, że prędkość zespołu rośnie (gdy tak naprawdę w dłuższym okresie raczej jest przede wszystkim niestabilna). Minusem mojego preferowanego podejścia jest konieczność rozbicia User Story na umowne mniejsze części i przyznanie Story Pointów tylko za część pracy jeszcze niewykonanej (np. tylko za brakujące code review i testowanie – w niektórych zespołach może to wprowadzić zamieszanie w zdefiniowanej skali).
Jeśli zamieszanie wywołane tym podejściem wydaje się zespołowi zbyt duże, pewnie lepszym wyborem będzie zdecydowanie się na jedno z dwóch pozostałych. Pozostawienie starej wyceny, mimo wykonania części pracy, jest najszybsze i najmniej podatne na ewentualną ingerencję (czy kreatywną księgowość w podwyższaniu wycen w zależności od sytuacji). Poddanie wycenie całego zadania takiej, jakby nie było zrealizowane, ale już z wiedzą z częściowego wykonania pracy, jest pewnie najbardziej precyzyjne z perspektywy chęci dokładnego wycenienia historyjki (co wcale nie powinno być jakimkolwiek celem), ale może zespół wciągnąć w niepotrzebną i czasochłonną dodatkową dyskusję o wycenie, ma też dodatkowy grzech mieszania wyceny pracy post factum. W tym podejściu pozwalamy na to, żeby do Sprintu wchodził element Backlogu z nieprawdziwą oceną jego wielkości. Bo historyjka częściowo wykonana to już nie jest 13 story pointów z pierwotnej wyceny, tylko zwykle mniej, ale użycie tej pierwotnej wartości może utrudnić zespołowi ocenę ilości pracy realnej do wykonania w Sprincie.
Na niebezpieczeństwo wyceniania całego zadania, z uwzględnianiem w wycenie pracy, która została już wykonana, wskazuje na swoim blogu Mike Cohn. W takiej wycenie post factum kompletnie odzieramy story pointy z elementów niepewności i złożoności (bo już po wykonaniu tej pracy dokładnie wiemy, z czego ta praca się składa, nie mamy niepewności, a złożoność została zredukowana do konkretnych zadań), upraszczamy je do czystej pracochłonności. Nie polecam reestymowania zadań po zrealizowaniu ich, zwłaszcza dla celów podbicia sobie statystyk. Dopuszczam taką ewentualność, że zespół może mieć ochotę na eksperyment związany z chęcią sprawdzenia jak ich oszacowania sprawdzały się w rzeczywistości – ale wtedy warto być czułym na argumenty powyżej i nie spalać energii na to, że szacunki okazują się być nietrafione. Możliwe, że taki eksperyment zaprowadzi zespół do odkrycia nurtu #NoEstimates lub zdecydowania się na dzielenie elementów Rejestru Produktu na znacznie mniejsze kawałki niż stosowane do tej pory.
W temacie tego artykułu toczyła się też ciekawa dyskusja na forum Scrum.org; warto prześledzić ją całą. Ważnym wnioskiem, który wyciągnął jeden z uczestników rozmowy, jest to, że akcent dyskusji usprawnieniowej zespołu powinien być położony na sprawienie, by co Sprint przygotować wartościowy przyrost i spełniać Cel Sprintu, a dyskusja o story pointach może stać się niepotrzebnym tematem zastępczym. Prawdopodobnie do rozwiązania mamy głębszy problem – dlaczego mamy zadania przechodzące między sprintami, co utrudnia nam zrealizowanie zaplanowanego przyrostu, ewentualnie dlaczego przejmujemy się tak bardzo, jak wypadają nam statystyki (miary scrum) typu velocity czy wykresy spalania.
A Wy jakie podejście do reestymowania wybieracie?
źródło zdjęcia https://flic.kr/p/5Cpnf1 udostępnione na licencji CC BY-NC-ND 2.0