Ponad rok temu w artykule na temat velocity opisywałem, czym jest praca nieukończona w Sprincie. Wyjaśniałem też, kiedy – w mojej ocenie – velocity Zespołu Scrum powinno być zerowe. Tym razem chciałbym pochylić się nad tym, co właściwie dzieje się z taką pracą nieukończoną w Sprincie i jak wpływa ona na velocity w kolejnych iteracjach.

Czym jest nieukończona praca?

Na początek warto przypomnieć, co w Scrumie stanowi pracę nieukończoną. Punktem odniesienia jest tu oczywiście Definicja Ukończenia i artefakt, jakim jest Przyrost. Nieukończoną pracą będzie wszystko, co Zespół Scrum realizował w Sprincie, a co nie zakończyło się powstaniem kolejnego Przyrostu (czyli nowej wersji produktu, wytworzonego zgodnie z wymogami Definicji Ukończenia).

Developerzy realizują w trakcie Sprintu zwykle więcej niż jedną zmianę w produkcie. Zdarza się, że każdy z nich pracuje nad czym innym, budując szereg różnych wersji produktów, które dopiero należy zintegrować w całość, by powstał Przyrost. Jeśli nie uda się tego zrobić przed końcem Sprintu, bo braknie czasu albo pojawią się problemy ze spełnieniem wymogów Definicji Ukończenia, nie powstanie ani jeden Przyrost. Wtedy wszystko, co Zespół realizował, stanowić będzie pracę nieukończoną.

Dobre Zespoły Scrum pracują nieco inaczej: ograniczają ilość zmian realizowanych jednocześnie lub wręcz robią to sekwencyjnie, dzięki czemu w trakcie Sprintu powstaje wiele kolejnych Przyrostów, z których każdy zawiera w sobie wszystkie poprzednie. Jeśli z jakiegoś powodu nie uda się czegoś ukończyć, zwykle jest to jedna lub dwie rzeczy, nad którymi Developerzy pracowali pod koniec Sprintu.

Niezależnie od przyczyn, dla których pracy nie udało się ukończyć i od jej ilości, Zespół musi podjąć decyzję, co z nią zrobić. A mówiąc precyzyjniej, decyzję tę podjąć musi Product Owner.

Co zrobić z niezrealizowanymi zmianami?

Product Owner nie może oczywiście uznać nieukończonej pracy za Przyrost – bo o tym rozstrzyga Definicja Ukończenia, która nie powinna być „uznaniowa”, tylko jednoznaczna. Jeśli Developerzy nie potrafią wykazać, że wymogi Definicji są na pewno spełnione, to znaczy, że Przyrost nie powstał.

O czym więc zdecydować ma Product Owner? O tym, w jaki sposób postąpić z tymi zmianami w produkcie, których ukończyć się nie udało. Błędem jest bowiem uznanie, że niezrealizowane elementy Backlogu Produktu „automatycznie przechodzą do kolejnego Sprintu”. Nie przechodzą ani automatycznie, ani w żaden inny sposób. Każdy Sprint w Scrumie jest przecież planowany świadomie przez cały Zespół Scrum dopiero w momencie rozpoczęcia iteracji.

Co więc dzieje się z takimi niezrealizowanymi w pełni elementami Backlogu Produktu? Tu właśnie pojawia się decyzja Product Ownera. Może on zasadniczo dokonać jednego z czterech wyborów.

1. Kontynuacja zmian, które wciąż są pilne

Jeśli to, czego nie zdołali ukończyć Developerzy, wciąż jest ważne i potrzebne jak najszybciej, niezrealizowane elementy powinny zostać umieszczone na początku Backlogu Produktu. Zwracam uwagę, że nie „przechodzą automatycznie do kolejnego Sprintu”, tylko wracają mimo wszystko do Backlogu Produktu. Dlaczego?

Powód jest oczywisty: konieczne jest uaktualnienie tych elementów tak, by opisywały one to, co jest do zrobienia teraz. Skoro jakieś prace już zostały wykonane, oryginalna definicja elementu może nie mieć wiele wspólnego ze stanem faktycznym, a to czyniłoby Backlog Produktu nieprzejrzystym.

Niewykluczone zresztą, że prac nie udało się ukończyć z powodu jakiegoś odkrycia, którego Developerzy dokonali w związku z tym elementem już w trakcie realizacji i konieczna jest zmiana strategii działania – a więc całkowite przedefiniowanie elementu Backlogu Produktu.

Konsekwencją zmiany (przedefiniowania) elementu Backlogu powinno być oszacowanie na nowo kosztów jego wytworzenia (wielkości, pracochłonności, czasochłonności czy czegokolwiek innego, co zwykle szacują Developerzy na prośbę Product Ownera). Jest to konieczne, ponieważ oryginalne oszacowanie jest już nieaktualne – element został częściowo zrealizowany, a następnie zmodyfikowany, dlatego jego nowa forma może wymagać dodatkowej pracy lub generować zależności, które należy uwzględnić podczas układania Backlogu Produktu oraz w trakcie Planowania Sprintu.

2. Odłożenie kontynuacji zmian na przyszłe Sprinty

Jeśli to, czego nie zdołali ukończyć Developerzy, wciąż jest potrzebne, ale przestało być pilne, Product Owner powinien umieścić niezrealizowane elementy w Backlogu Produktu na nieco dalszej pozycji, którą uzna za właściwą. Oznaczać to będzie, że Zespół wróci do ich realizacji w jednym z przyszłych Sprintów, być może za dłuższy czas.

Także i w tym przypadku konieczne jest przedefiniowanie takich częściowo zrealizowanych elementów. W ten sposób jasne staje się, co zostało do zrobienia. Skoro zmienia się opis elementów, konieczne jest dokonanie na nowo oceny kosztu ich realizacji tak, by „stare” oszacowania nie wprowadzały Zespołu w błąd.

3. Połączyć kontynuację zmian z innymi elementami Backlogu

Czasami nieukończona praca stanowi jedynie pierwszy etap jakiejś bardziej rozbudowanej modyfikacji produktu, co oznacza, że w Backlogu Produktu istnieją elementy opisujące ten ciąg dalszy. Jeśli tak, Product Owner może zdecydować o usunięciu (zamknięciu bez rozwiązania) nieukończonych elementów i dołączyć pracę, jaka pozostała w nich do wykonania, do elementów opisujących kolejne etapy rozwoju produktu.

Ponieważ dochodzi wtedy do zmiany definicji takich elementów Backlogu, konieczna może być zmiana oszacowania kosztu ich realizacji, identyfikacja zależności, zmiana kolejności na liście itd. Choć wydaje się to pracochłonne, jest to najlepsza strategia, ponieważ Zespół skupi się na uzyskiwaniu kolejnej wartości, zamiast bawić się w „dożynki” tego, czego nie udało mu się skończyć w Sprintach poprzednich.

4. Rezygnacja z dalszych prac

Jeśli niezrealizowane zmiany w produkcie nie są już potrzebne, bo sens ich budowania istniał tylko do pewnego momentu, który już minął, Product Owner może usunąć element Backlogu Produktu całkowicie bez rozwiązania. Oznacza to, że prace nad nieukończoną zmianą w produkcie nie będą kontynuowane.

Podobnie może się stać, jeśli Product Owner uzna, że kontynuowanie prac jest po prostu nieopłacalne, bo potencjalna korzyść z ich dokończenia nie uzasadnia dalszej inwestycji w tę konkretną zmianę. Sporo zależeć tu może od tego, jak wiele pracy pozostało do wykonania, dlatego przed podjęciem takiej decyzji Product Owner zapewne poprosi Developerów o stosowne oszacowanie.

Kto posprząta bałagan…?

Niezależnie od tego, którą z opcji wybierze Product Owner, Developerzy muszą zapewnić, że częściowo niezrealizowane zmiany w produkcie nie mają wpływu na możliwości jego dalszego rozwoju i użytkowania tych funkcjonalności, jakie zostały już ukończone. Inaczej mówiąc, Developerzy muszą doprowadzić produkt do stanu zgodności z wymogami Definicji Ukończenia. Prace te, co oczywiste, nie muszą i nawet nie powinny być opisane w formie elementu Backlogu Produktu, ponieważ jest to część pracy Developerskiej, opisywanej Backlogiem Sprintu.

Dlatego może okazać się, że po Sprincie, w którym czegoś nie udało się ukończyć, nawet jeśli Product Owner podejmie decyzję o odstąpieniu od kontynuowania prac, Developerzy w trakcie Planowania Sprintu kolejnego muszą uwzględnić konieczność posprzątania bałaganu – usunięcia zmian, które wykonali wcześniej. Tym samym Zespół zrealizuje w tej iteracji mniej nowych zmian w produkcie, niżby chcieli interesariusze. Cóż, jak widać, umiejętność kończenia prac rozpoczętych w Sprincie naprawdę jest przydatna…

Wpływ nieukończonej pracy na velocity

Jeśli realizacja elementu Backlogu Produktu nie została ukończona w Sprincie, w którym się rozpoczęła, to tej pracy w kalkulacji prędkości dla bieżącego Sprintu nie uwzględniamy. Przykładowo, jeśli Developerzy podjęli do realizacji dziesięć elementów z Backlogu Produktu i każdy z nich udało im się wykonać na „99%”, to ponieważ ani jeden nie został ukończony, velocity jest dokładnie zerowe. Nie służy ono bowiem ocenie tego, czy Developerzy ciężko pracowali, tylko jest miarą tempa „zjadania” Backlogu Produktu. A tu nic nie udało się „zjeść”, skoro wszystko wciąż pozostaje do zrobienia, nawet jeśli to „tylko 1%” (o tym za moment).

Co się stanie, jeśli Product Owner umieści niezrealizowane elementy na powrót w Backlogu Produktu? Zostaną one prawie na pewno podjęte do jednego z kolejnych Sprintów i w nim ukończone. Tyle że wcześniej zostaną przedefiniowane, by odzwierciedlać pracę, jaka pozostała do wykonania (ów „tylko 1%”). Co oznacza, że ich ukończenie w tym przyszłym Sprincie będzie miało nikły wpływ na velocity tej iteracji. Inaczej mówiąc, część pracy wykonanej przez Developerów nie zostanie uwzględniona ani w velocity Sprintu, w którym zaczęła się realizacja zmiany w produkcie, ani iteracji, w której ta realizacja się zakończyła.

Ktoś krzyknie: ależ to bez sensu, bo przecież praca została wykonana! Odpowiem na to przypomnieniem, że velocity nie jest miarą pracowitości Developerów, ale odzwierciedleniem ich umiejętności kończenia prac w Sprincie nad tym, czego realizacji się podejmują. Powinno być niskie, jeśli mają z tym problem. A „dożynki” prawie już skończonych zmian nie powinny sztucznie podbijać velocity w górę.

Malowanie trawy na zielono

Rozważmy najpierw scenariusz skrajny, bo na takich przykładach najlepiej da się wykazać absurdy niektórych strategii działania. Otóż mamy Zespół Scrum, który od dwóch lat pracuje w dwutygodniowych Sprintach, więc ma za sobą już 100 iteracji. W żadnym z tych Sprintów nie udało mu się niczego ukończyć, choć za każdym razem osiąga „99%” gotowości. Product Owner za każdym razem decyduje, by nie kontynuować prac nad nieukończonymi elementami Backlogu Produktu, bo pojawiają się nowe, pilniejsze potrzeby.

W oczywisty sposób velocity tego Zespołu powinno być zerowe we wszystkich zakończonych Sprintach. Zakładam, że nikt nawet nie próbowałby bronić tezy, że jest inaczej. I to pomimo tego, że Developerzy ciężko pracowali przez te dwa lata. Efektów ich pracy brak, a jedynym powodem, dla których posuwają się w Backlogu Produktu do przodu, jest wywalanie do śmietnika kolejnych nieukończonych elementów przez Product Ownera.

Rozważmy nieco mniej skrajny scenariusz: Zespołowi udaje się ukończyć to, co realizuje, ale tylko co drugi Sprint. W nieparzystych iteracjach wszystko jest zrobione na „99%”. Product Owner decyduje za każdym razem o kontynuacji prac, umieszczając niezrealizowane elementy na początku Backlogu Produktu – ale nie są one na nowo szacowane, żeby „nie stracić velocity”. W parzystych iteracjach praca nad nimi jest kończona, a że nie zabiera to dużo czasu (bo to „tylko 1%”), Developerzy są w stanie zrealizować jeszcze szereg innych zmian w produkcie.

Jak będzie kształtować się velocity Zespołu w tym przypadku? Ano, w nieparzystych Sprintach będzie zerowe, w parzystych bardzo wysokie, bo odzwierciedlać będzie pracę wykonaną de facto w dwóch iteracjach. Średnia prędkość będzie całkiem wysoka i… kompletnie niewiarygodna. Dlaczego?

Product Owner użyje wiedzy o velocity do prognozowania dat realizacji poszczególnych elementów Backlogu Produktu. Sięgając po tak wyliczoną średnią prędkość, określi te daty tak, jakby co Sprint Developerom udawało się dużo zrobić. Tyle że im udaje się to tylko co drugą iterację. W efekcie, w najlepszym razie, Product Owner może pomylić się w jeden Sprint. I rozminąć się o ten jeden Sprint z jakimś krytycznym terminem.

Przejrzystość przede wszystkim

Co stałoby się, gdyby Developerzy z przykładowego Zespołu zmieniali oszacowania nieukończonych elementów za każdym razem, gdy wracają one do Backlogu Produktu? Jeśli faktycznie do zrobienia zostało „tylko 1%”, nowe oszacowania będą bardzo niskie. W parzystych Sprintach, gdzie praca jest kontynuowana, będzie ona miała niewielki wpływ na velocity, które wynikało będzie przede wszystkim z nowych elementów, podjętych do realizacji w tych parzystych iteracjach.

Średnie velocity w tym przypadku będzie o połowę niższe, bo odzwierciedlać będzie tylko to, co na przestrzeni wielu Sprintów udaje się skończyć. Blisko połowa pracy, jaką Developerzy wykonują, nigdy nie „odłoży się w velocity”, ale przynajmniej Product Owner dostanie realną miarę tempa, w jakim realizowany jest Backlog Produktu. Poza tym w każdym momencie oszacowania elementów w tym Backlogu odzwierciedlają to, co wciąż jest do zrobienia (a nie co jest już w „99%” gotowe).

Dlaczego Zespoły postępują inaczej?

Wbrew logice i zasadom Scruma, który wymaga praktycznego stosowania empiryzmu, Zespoły często trzymają się jednak oryginalnych oszacowań i na ich bazie wyliczają swe velocity w tym Sprincie, w którym pracę uda się wreszcie ukończyć. Są też takie Zespoły, które szacują, ile procent pracy zostało wykonane w iteracji, w której realizacji nie udało się ukończyć i doliczają sobie do velocity tego Sprintu procentową część oszacowania, bo „praca przecież była wykonywana”.

Zespoły te oszukują same siebie. Utrzymują swoje velocity na niezłym poziomie, odzwierciedlającym możliwości wytwórcze, których tak naprawdę nie są w stanie osiągnąć. Dlaczego to robią? Bo nie rozumieją, czym jest velocity. Bo są rozliczane przez management ze swego velocity (to głupota, ale niestety bardzo częsta w wielu organizacjach). Bo podświadomie (albo i całkiem świadomie) chcą ukryć problem z organizacją pracy developerskiej.

Narzędzie prognozowania i sygnał alarmowy

Jeśli Zespół zdecydował się na wyliczanie swego velocity, powinien robić to w taki sposób, by służyło ono skutecznie dwu celom:

  1. sporządzaniu prognoz potencjalnych dat realizacji poszczególnych elementów Backlogu Produktu (to zwykle robi Product Owner),
  2. ujawnianiu nieefektywności lub nieskuteczności działań Developerów, co pozwoli dokonać niezbędnych usprawnień.

Jeśli velocity Zespołu jest dramatycznie niskie, mimo że Developerzy ciężko pracują, to powinni poszukać takiego sposobu postępowania w Sprincie, by ciężka praca przekładała się na realne efekty: działające Przyrosty, zawierające wartościowe rozwiązania, których potrzebują interesariusze (np. użytkownicy produktu).

To, że Developerów zaboli fakt, iż napracowali się, a velocity w ogóle nie wzrosło, ma szansę wykreować presję do działania, by coś z tym zrobić. Podobnie jak fakt, że wykonana praca „nie odłożyła się” w velocity żadnego Sprintu w przypadku elementów Backlogu, nad którymi praca rozłożyła się na wiele iteracji. W kontrze do tego stoi sztuczne utrzymywanie velocity na wysokim poziomie niezależnie od tego, czy coś udało się ukończyć, czy nie. Developerzy mogą nie mieć powodu, by coś z tym zrobić, bo przecież „jest dobrze, prawda?”.

A może przestać liczyć to nieszczęsne velocity?

Przyznam, że od dawna uważam za mało sensowne zarówno typowe „szacowanie wymagań”, jak i dalsze ich przetwarzanie np. właśnie poprzez wyliczanie z nich prędkości Zespołu. Bardzo często celem szacowania jest „mieć estymaty”, równie często kalkulacja velocity służy wykazaniu, jak to pracowity jest Zespół. Obie te rzeczy są chybione, jeśli mówimy o metodach zwinnych, takich jak Scrum, które nie służą organizacji pracy Zespołów, tylko uzyskaniu korzyści dla interesariuszy.

Już niedługo (tym razem na serio niedługo, zapewniam) napiszę, czego użyć zamiast velocity i jak zmieść z planszy oszacowania, a mimo to dbać Pielęgnację Backlogu Produktu i sporządzać wartościowe prognozy dat realizacji poszczególnych jego elementów.

Oddzielenie tego, co ukończone, od nieukończonego

Pisząc o sposobie postępowania z pracą nieukończoną, celowo pominąłem jeden przypadek, z którym Zespoły Scrum mogą się zetknąć. Chodzi o sytuację, w której Developerzy, wiedząc, że czegoś już nie uda się skończyć, dokonują wraz z Product Ownerem dekompozycji realizowanych elementów Backlogu Produktu tak, by oddzielić to, co wciąż możliwe do ukończenia, od reszty, na którą czasu zabraknie.

Dlaczego nie wspomniałem o tym wcześniej? Bo w praktyce nie ma tu do czynienia z pracą nieukończoną. Dzięki dekompozycji da się uniknąć trudnych decyzji o dalszym losie „rozgrzebanych” elementów Backlogu Produktu, a Product Owner ma nieco więcej czasu, by zdecydować, co zrobić z tą częścią prac, jakich nie udało się wykonać.

Przy czym absolutnie nie chodzi tu o bezmyślny podział dokonywany tylko po to, by „zalegalizować” prace w bieżącym Sprincie jako ukończone. Inaczej mówiąc, kryterium podziału wciąż musi być wartość, jaką stanowić dla interesariuszy będzie to, co zostanie ukończone. Najlepiej objaśnić to na przykładzie.

Załóżmy, że realizowana jest jakaś funkcjonalność, która może być użyta na pięć różnych sposobów. Developerzy zdołali wytworzyć mechanizmy niezbędne do trzech zastosowań, ale na dwa kolejne już braknie czasu. Product Owner, poinformowany o tym, zgadza się, by element Backlogu Produktu został podzielony. Jedna część opisywać będzie tylko trzy z pięciu sposobów użycia funkcjonalności – te, które jest szansa ukończyć w bieżącym Sprincie. Druga część, opisująca dwa pozostałe sposoby użycia, stanowić będzie nowy element Backlogu Produktu.

Takie działanie jest w pełni zgodne z zasadami Scruma, w którym chodzi o dążenie do uzyskania maksimum możliwej wartości dla interesariuszy, ale też o uzyskanie produktu, który być może jest mniej zaawansowany, niż planował Zespół, za to działający.

A teraz wyobraźmy sobie, że ten sam Zespół ma rozwiązanie niemal gotowe dla wszystkich pięciu przypadków użycia, tyle że nie zdołał wytworzyć interfejsu użytkownika, który pozwalałby na ich wykorzystanie. Czy miałby sens podział prac na „to, co już działa od strony technicznej” i „dobudowanie interfejsu”? Nie, ponieważ w praktyce bez tego interfejsu nic nie działa. To „działanie” sprowadzałoby się do pokazania za pomocą narzędzi developerskich, że „jeśli kiedyś powstanie interfejs, to jego użycie dałoby takie efekty”. Tyle że tego interfejsu nie ma, więc użytkownicy nijak z tej funkcjonalności częściowo zrobionej nie mogą skorzystać.

Czy mimo wszystko taki podział nie byłby zgodny z zasadami Scruma? Formalnie da się tę tezę obronić, ale przecież to byłoby wykazywanie na siłę, że Sprint poszedł dobrze. Komu chcemy to udowodnić? Bo przecież nie interesariuszom, dla których realnie nic nie mamy…

Z kronikarskiego obowiązku dodam, że taki podział na to, co zostanie dokończone i to, co przeniesione zostanie do Backlogu Produktu, nie powinien zdarzać się nagminnie i nie może następować już po zakończeniu prac developerskich. Jest to elegancka i sensowna opcja działania w wyjątkowej sytuacji dla Zespołów, które co do zasady nie mają problemów z dostarczaniem wartości. Zdecydowanie nie jest to rozwiązanie dla Zespołu partaczy, którym czasami uda się coś ukończyć, ku zaskoczeniu siebie i interesariuszy.