Jak DoD wpływa na wycenę wymagania? 

Jednym z tematów, który ostatnio do nas trafił jest wpływ Definition of Done na wycenę elementów Backlogu Produktu. Zajmijmy się nim dzisiaj, ale najpierw przyznamy się, skąd się to pytanie w ogóle wzięło.

Skąd pytanie?

Jak wiecie (a może jeszcze nie, ale właśnie się to zmienia) napisaliśmy książkę o szacowaniu. 141 popełnionych przez nas stron zostało przyjęte naprawdę ciepło. Jak to zwykle bywa, nie obyło się bez kilku kontrowersji. Część wyjaśnień rodzi dodatkowe pytania – i dobrze! A jeszcze lepiej, że się nimi z nami dzielicie.

Dziękujemy za wszystkie otrzymane komentarze będące wynikiem dokonywanych recenzji i czekamy na więcej. Zajmiemy się nimi na naszym zwinnym blogu w tekstach takich jak dzisiejszy oraz na naszym kanale na YouTube.

A tymczasem wróćmy do wpływu Definition of Done na wycenę elementów znajdujących się w Backlogu Produktu.

Wpływ

Skoro powyżej zapytałem „Jak wpływa?” to jest to znak, że ten wpływ istnieje. Aby dobrze zobrazować odpowiedź na dzisiejsze pytanie naszkicujmy sobie naszą uproszczoną i przykładową DoDę:

• Funkcjonalność została przetestowana
• Kod rozwiązania został poddany Code Review, a ewentualne uwagi zostały uwzględnione
• Utworzono dokumentację zmian w funkcjonalności

Stwierdzenie przez Scrum Team, że realizacja wymagania została zakończona wymaga każdorazowego spełnienia 3 powyższych kryteriów. Punkty te w oczywisty sposób wpływają na zakres prac planowanych do realizacji. Tworząc plan wykonania wymagania, będziemy musieli wziąć pod uwagę potrzebę przetestowania rozwiązania, weryfikacji kodu zgodnie z przyjętymi standardami CR oraz udokumentowania zmiany. Oznacza to, że czynności te wpływają w oczywisty sposób na rozwiązanie, które tworzymy.

W zależności od tego, jak duże jest realizowane wymaganie, spełnienie powyższych punktów Definicji Ukończenia będzie mniej lub bardziej skomplikowane. Przykładowo, jeśli zajmujemy się dodaniem nowej ikonki do ekranu startowego aplikacji, zmiana w dokumentacji powinna zamknąć się w 5 min. Jeśli zmieniamy algorytm wskazania preferowanego kuriera (który ma dostarczyć zakupioną przez Klienta paczkę), ilość zmian w dokumentacji będzie większa.

Jak wycenić realizację DoD?

Jak wycenić spełnienie kryteriów Definition of Done? Odpowiedź wydaje się być oczywista – tak samo jak szacujemy każde inne wymaganie. Na pewno zanim podejdziemy do wyceny tego typu elementów, musimy dobrze poznać zakres wymagania, którym będziemy się zajmować. Wycena, czy to wielkości prac związanych ze spełnieniem DoD, czy prac związanych z realizacją samego wymagania nie będzie możliwa bez przeprowadzenia Product Backlog Refinementu.

W tym miejscu często pojawia się pomysł „ryczałtowego” potraktowania elementów DoD. Skoro są to tzw. stałe reguły gry, które tak czy owak za każdym razem musimy spełnić, załóżmy narzut na ich realizację, który za każdym razem będziemy braki pod uwagę. „Narzuty”, z jakimi spotkałem się w swojej karierze wyrażone były np. w Story Points (na spełnienie DoD dorzućmy plus 1 pkt) lub w godzinach (np. 8h). Ze względu na zmienność wielkości tych prac takie potraktowanie sprawy nie jest jednak realne.

Podchodząc do wyceny realizacji DoD musimy zmierzyć, z czym mamy do czynienia. W części przypadków istnieje pewna korelacja między wielkością wymagania, a wielkością prac, które musimy zrealizować aby zrealizować DoD. „Tylko w części”, bo jak doskonale wiemy wycena wymagania uwzględnia w sobie np. kwestię niepewności czy ryzyka związanego z realizacją wymagania. Wszyscy znamy też wymagania z kategorii „5 minut zmiany w kodzie i konieczność tygodniowych testów regresji”. Istnieją też przypadki odwrotne.

Wracając do przykładu dodania nowej ikonki na ekranie startowym, samo spełnienie DoD będzie szybkie, ale „ciężkie” może okazać się  uzgodnienie konkretów z Interesariuszami. Wycena wymagania będzie więc „wysoka”, ale wielkość prac związanych ze spełnieniem DoD – niewielka.

Jak DoD wpływa na wycenę wymagania?

DoD może mieć duży wpływ na wycenę wymagania. Uproszczona Definicja Ukończenia, którą stworzyliśmy na cele niniejszego wpisu jest najkrótszą, z jaką miałem do czynienia. Łatwo się więc domyśleć, że w prawdziwym „życiu” wpływ DoD na wycenę wymagania będzie jeszcze większy. Im więcej elementów musimy wziąć pod uwagę, tym większa szansa, że spowodujemy kaskadę, gdzie drobna zmiana będzie miała wielkie konsekwencje.

Nie bez powodu jedną z rzeczy, które zespoły powinny wziąć pod uwagę podczas Planowania Sprintu są właśnie zapisy DoD.  Konieczność spełnienia kryteriów powoduje, że w wielu przypadkach pierwotnie planowane do realizacji wymagania będą niemożliwe do dostarczenia (w części lub całości) w jednym Sprincie. Stanie się tak, ponieważ nie spełnimy kryteriów Definicji Ukończenia, np. przetestowania (zbyt duże zmiany) bądź zapewnienia Code Review (niedostępność kluczowych osób).

Zastanawiając się nad tym, jak DoD wpływa na wycenę wymagania nie możemy też pominąć kwestii zależności. Są miejsca, gdzie spełnienie DoD wymaga zaangażowania osób które nie są Deweloperami w naszym zespole lub nie będących jego stałą częścią. Fakt ten, czyli konieczność zagwarantowania udziału tych osób w proces uznawania wymagania za zakończone, musimy wziąć również pod uwagę. Zupełnie osobną kwestią jest to, czy Definition of Done, którego nie jesteśmy w stanie spełnić siłami naszego zespołu jest dobrym DoD. Ale to temat na zupełnie inny tekst…