Czy reestymować zadania które przechodzą między sprintami?

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ściaPrzykładDefinicja
Oszacuj pracę pozostałą do wykonaniaDo 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ówNa 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 zadaniaDo 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 ProduktuZakł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śmyTrzymaj 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 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

Komentarze do wpisu: “Czy reestymować zadania które przechodzą między sprintami?

  1. To bardzo dobre podsumowanie! W każdym zespole, z którym pracowałem i który używał SP, w pewnym momencie pojawiał się temat re-estymacji nieskończonych zadań i zwykle powodował on sporo dyskusji oraz emocji…

    Moje 0,03 zł:

    1. Dobrze jest jeżeli Scrum Master traktuje SP jako narzędzie, a nie jako religię objawioną – i w momencie pojawienia się wątpliwości zachęca zespół do wspólnej dyskusji. Niestety znam Scrum Masterów, którzy mają swoją koncepcję używania SP i kurczowo się jej trzymają…

    2. Jeżeli traktujemy SP jako narzędzie, to dobrze jest zacząć dyskusję od celu używania tego narzędzia. Czyli od zadania pytania „do czego tak naprawdę potrzebujemy tych punktów? Jaką wartość nam przynoszą?”. Ja znam dwa cele używania SP:
    a) pomoc zespołowi w dobrym zaplanowaniu sprintu („ile historyjek powinniśmy wziąć do sprintu?”)
    b) pomoc PO w prognozwaniu postępów prac („za ile sprintów możemy skończyć dany zbiór historyjek?”)

    Jeżeli skupiamy się na pomocy zespołowi w planowaniu, najlepsze jest podejście pierwsze czyli „oszacuj pracę pozostałą do wykonania”. Jeżeli stosujemy podejście drugie lub trzecie, to i tak w głowie musimy szybko przeliczać: „ta historyka ma zapisane 21 SP, ale większość już zrobiona, to zostało może 5-8”. Każdy deweloper przelicza sobie sam, brakuje nam przejrzystości.

    Jeżeli skupiamy się na pomocy PO w prognozowaniu, to teoretycznie lepszym podejściem wydaje się podejście drugie „Reestymuj do nowej wyceny całości zadania” – ale nie spotkałem jeszcze zespołu, który by używał tego podejścia i był z tego zadowolony 

    3. Też spotykam się z tym, że podejście „oszacuj pracę pozostałą do wykonania” powoduje emocjonalną reakcję zespołu: „ale to niesprawiedliwe, wykonaliśmy większość pracy, nie skończyliśmy zadania bo (tutaj jakieś racjonalne wytłumaczenie) – a teraz nie mamy za to żadnych punktów? To nie po krasnoludzku!”. I to może być bardzo dobry wstęp do zadania pytania o wartość nieskończonych zadań. Jaką wartość dla użytkowników naszego systemu ma to, że mamy zadanie „zrobione ale nie przetestowane”?

    4. Pracowałem w organizacji, w której 6 zespołów rozwijało jeden produkt. Większość zespołów stosowało podejście „oszacuj pracę pozostałą do wykonania” – ale nie wszystkie. Mocno utrudniało to przejrzystość wykresów prędkości, które były publikowane wspólnie. W większej skali pojawia się konflikt pomiędzy wolnością zespołu a organizacją pracy w szerszym kontekście.

  2. Cześć Staszek, dzięki za Twój rozbudowany komentarz!

    Dobrze dodałeś ten niuans o celu używania SP – faktycznie ma to wpływ na to, jaką strategię wybrać i w ogóle dużo wartościowej rozmowy w zespole może wyniknąć, gdy zaatakujemy temat „co nam daje to narzędzie” a nie skupianie się na jednej jedynej słusznej wersji.

    >>Jeżeli skupiamy się na pomocy PO w prognozowaniu,
    >> to teoretycznie lepszym podejściem wydaje się podejście
    >> drugie „Reestymuj do nowej wyceny całości zadania”

    W podejściu pierwszym zmniejszenie estymaty za częściowo wykonane zadanie zmniejszy też sumę wszystkich SP z user stories jakie pozostały do wykonania w backlogu (czy spięte w ramach epica), więc na release / epic burndown chart zobaczymy spadek wykresu – do prognozowania przez PO to też da rezultat.

    >> W większej skali pojawia się konflikt pomiędzy wolnością zespołu
    >> a organizacją pracy w szerszym kontekście.

    Oj tak, piękny temat na długi felieton, mam go nawet w planie na swojego bloga – na podstawie przeżyć z toczącej się u mnie transformacji. Takie rzeczy jak wspólna narzędziówka (git, sonar, …), jedna interpretacja jakiejś zasady, minimalny poziom Definicji Ukończenia czy jak z przypadku tego artykułu – wspólne podejście do szacowania, by wyciągać podobne wnioski z narzędzi stosowanych przez wszystkie zespoły – ładnie otwierają przestrzeń na dyskusje o granicach między anarchią a ładem i jak się to ma do agile.

    pozdrawiam, Kuba

  3. Piotr Gruszczyk

    Kuba, Dzięki za ten wpis! Zachęca do refleksji 🙂

    Sam już od lat jestem wielkim zwolennikiem podejścia trzeciego właśnie ze względu na to, że po kilku iteracjach zespół sam uczy się, że nie warto tworzyć ogromnych backlog itemów – warto natomiast skupić się na zrozumieniu przyrostu na końcu sprintu. Bardzo ładnie współgra to z sumiennym podejściem do DoD – jeśli szacowaliśmy 13sp to albo jest done (spalone) albo nie jest (13sp do zdobycia ciągle przed nami). Taka samodyscyplina. 🙂
    Re-estymacja przez zespół spadowicza (tak jak w propozycji pierwszej) dzieje się naturalnie, gdy zespół planuje kolejny sprint i szacuje swoje możliwości – po prostu nie aktualizujemy tej wartości w narzędziu. Jeśli przestrzeliliśmy to trudno – skoro nie zmniejszamy zbyt dużych estymat które zamknęliśmy szybciej niż się spodziewaliśmy – to jaki ma cel modyfikować zbyt małe lub/i niedokończone?

    Z mojego doświadczenia właśnie to podejście wzmacnia akcent dostarczania przyrostu i oddala zespół scrumowy od pułapki dążenia do idealnego burndownu. Nie mniej jednak – tak jak napisałeś – każdy z nich ma swoje wady i zalety.

  4. Ten temat prawie zawsze wywołuje silne emocje i daje paliwa na wiele dyskusji na retro/kawie/piwie, dzięki za rzetelne podsumowanie 🙂

    Choć podejście pierwsze ma pewne wady to w przeciwieństwie do pozostałych raczej nie maskuje innych, głębszych problemów jak to często ma miejsce przy podejściach #2 i #3 (np. traktowanie estymat jako zobowiązań; oceniania zespołu na podstawie velocity; wiara, że stabilne velocity dziś jest gwarancją przewidywalności, etc).

    Jeśli chodzi o podejście trzecie to jego wady ujawniają się wyraźniej w przypadku produktów, w których priorytety zmieniają się bardzo dynamicznie i nie ma gwarancji, że historyjki będą „z automatu” przechodzić ze sprintu na sprint. W takiej sytuacji nieukończona historyjka lub historyjki (jeśli jest ich więcej np. z wcześniejszych sprintów) będą fałszować całościowy szacunek pracy pozostałej do wykonania w backlogu. Innym problemem jest narzut pamiętania lub śledzenia „tej prawdziwej estymaty”, skoro w narzędziu/na tablicy zostawiamy estymatę oryginalną. I last but not least „ta prawdziwa estymata” sama powinna podlegać uaktualnieniu tym częściej im dłużej taka nieukończona historyjka wisi w backlogu.

  5. Hej,

    Twoja propozycja „wycięcia” nieskończonej pracy jako swoista „kara” to dosyć odważne podejście. Niemniej, ja osobiście zawsze doradzam przepisanie całości bez reestymowania. Dlaczego nie estymować ponownie, to wyjaśniłeś – mieszamy estymaty (z niepewnością) z tak na prawdę „raportem” (bo znamy już skomplikowanie).

    Przepisanie estymaty „napompuje” aktualny sprint – to prawda, ale:
    – średnie velocity liczone ze wszystkich sprintów będzie bliższe prawdy
    – te przykładowe 13 punktów „zapcha” aktualny sprint, co spowoduje, że zespół weźmie na ten sprint mniej. Oczywiście te 13 punktów spali się np po odpowiedniku 3 punktów, ale że nie dobieramy do sprintu, zanim wszystkie zadania ze sprint backlogu nie zejdą, to wymusi to dyscyplinę w zespole, by Ci najpierw wzięli taski, które są, dowieźli je do końca i dopiero na koniec sprintu ustalili z PO co dobrać, co będzie odpowiednio małe, by skończyć jeszcze w aktualnym sprincie.
    Dzięki temu podejściu zespół będzie szybciej dochodził do swojej optymalnej prędkości. Twoja propozycja oznacza, że zespół „dopycha” te oszczędzone 10 punktów na początku sprintu i znów może ulec swojemu optymizmowi i znów skończy z nieskończonym zadaniem, co nie przybliży go do zrozumienia, jakie są prawdziwe możliwości zespołu.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x