Definicja Gotowości

Definicja Gotowości jako zamach na fundamenty

Definition of Ready, czyli w luźnym tłumaczeniu Definicja Gotowości, nie jest elementem Scruma. Jest natomiast częstą praktyką wykorzystywaną przez Zespoły Scrumowe w codziennej pracy. Zdarza się, że stosowana jest przez Developerów jako tarcza chroniąca przed zobowiązaniem się do niedostatecznie dobrze opisanego elementu Backlogu. PBI jest odrzucony podczas Planowania, a Product Owner ma wyrzuty sumienia, że źle przygotował opis zadania. Jeżeli ta sytuacja brzmi znajomo, to zapraszam Cię do dalszej lektury.

Czym jest Definicja gotowości?

Definicja Gotowości (ang. Definition of Ready, DoR) opisuje stan elementu Product Backlogu, który musi zostać przez niego osiągnięty, zanim będzie realizowany przez Developerów w Sprincie. Najczęściej jest to lista będąca zbiorem koniecznych do spełnienia warunków.

Celem Definicji Gotowości jest zwiększenie jakości elementów Product Backlogu. Dzięki niej Zespół minimalizuje ryzyko zobowiązania się podczas Planowania do wykonania elementu Backlogu, którego realizacja okaże się problematyczna ze względu na brak wystarczającej ilości szczegółów.

Przykładowe Definition of Ready może wyglądać tak:

    • PBI jest ujęty w formacie User Story,

    • PBI ma estymatę, która jest dostatecznie mała, by zmieścić realizację zadania w Sprincie,

    • PBI ma jasne Kryteria Akceptacji,

    • PBI spełnia kryteria INVEST (Independent, Negotiable, Valuable, Estimable, Testable)

Co mówi Scrum Guide?

Definicja Gotowości nie jest elementem wpisanym we framework Scrum. Scrum Guide wskazuje jedynie: „Elementy Product Backlogu, które mogą zostać Ukończone przez Scrum Team w trakcie jednego Sprintu, zostają uznane za gotowe do wybrania podczas Sprint Planningu.” [1]. Zatem jedyny obowiązkowy do spełnienia warunek dotyczy rozmiaru elementu. PBI musi być wystarczająco mały, by jego ukończenie (spełnienie Definicji Ukończenia) było możliwe w trakcie trwania pojedynczego Sprintu.

Negatywne skutki korzystania z Definicji gotowości

Zamysł Definicji Gotowości wydaje się słuszny. W praktyce jednak jej wykorzystanie może być tytułowym „zamachem” na fundamentalne założenia, które są kluczowe dla sukcesu implementacji Scruma. Poniżej przedstawiam negatywne skutki, które może przynieść korzystanie z Definition of Ready.

Wskazane negatywne skutki stosowania Definicji Gotowości: blokuje wspólpracę, potęguje brak zaufania, utrudnia empiryzm.

#1 Blokuje współpracę

Definicja Gotowości przyjmuje formę kontraktu między Product Ownerem a Developerami [2]. Brak spełnienia poszczególnych warunków DoR przez PBI powoduje, że Developerzy protestują przeciwko jego realizacji. Nie podejmują otwartej współpracy w celu określenia koniecznych szczegółów.

DoR może być niekiedy (złym!) pomysłem na usprawnienie „słabego” Product Ownera. PO dostaje listę tego, co musi uzupełnić w PBI, by Developerzy mogli go realizować. Zamiast Zespołowo podjąć próbę ustalenia najlepszego sposobu na osiągnięcie oczekiwanego rezultatu, to Developerzy wymagają, by Product Owner wszystko wymyślił, opisał w formie wymagań i dopiero wtedy przekazał do realizacji.

DoR jest wtedy najczęściej sprawdzane i używane podczas Planowania. Developerzy chowają się za Definicją Gotowości i w przypadku braku elementu ustalonego w DoR, nie podejmują się realizowania danego zadania.

#2 Potęguje brak zaufania

Definicja Gotowości jest wynikiem braku zaufania w Zespole. Gdy nie udaje się osiągnąć Celu Sprintu lub dostarczyć rozwiązania na czas i zgodnie z potrzebami, Developerzy, Product Owner i Interesariusze zamiast współpracować, wzajemnie się obwiniają. Product Owner i Interesariusze zrzucają na Developerów winę za brak sukcesów, a Developerzy odbijają piłeczkę twierdząc, że wymagania były źle sformułowane. Przepychanki kto czego nie zrobił i dlaczego nie wywiązał się z określonych warunków jedynie pogłębiają brak chęci do współpracy.

W ramach naprawy sytuacji tworzona jest Definicja Gotowości, która jedynie potęguje brak zaufania i wznosi mur między poszczególnymi partiami. DoR jest wtedy używane jako tarcza na Product Ownera, która często generuje wzrost jego frustracji, pogłębiając dysfunkcję relacji w Zespole.

W takim środowisku Zespół nie będzie chętny do podejmowania jakiegokolwiek ryzyka z obawy przed niepowodzeniem.

#3 Utrudnia empiryzm

Zespół kurczowo trzyma się warunków określonych w Definicji Gotowości, a PBI pełne specyfikacji traktuje jak wyryte w kamieniu. Skrupulatnie je realizuje, bez refleksji na temat doświadczenia płynącego w trakcie realizacji zadania. Zespół zatraca umiejętność adaptacji i proaktywnego szukania najlepszych rozwiązań. I tak oto wpadamy w pułapkę waterfalla, nieświadomie rezygnując z empirycznego podejścia do tworzenia Produktu.

Wyobraźmy sobie sytuację, w której podczas Sprint Review zyskujemy cenny feedback. Product Owner uznaje za wartościowe rychłą jego implementację w nadchodzącym Sprincie. Nie było jednak czasu na opracowanie tematu z Zespołem. Podczas Planowania Zespół wyciąga kartę „Definicji Gotowości” by odrzucić pomysł Product Ownera. Właśnie straciliśmy szansę na adaptację, będącą filarem empiryzmu.

Innym przykładem mogą być zadania, których specyfikacji nie da się jasno określić. Myślę tu o eksperymentach i SPIKEach. Te z natury będą miały nieoczywisty przebieg i rezultat, nawet jeżeli określimy ich ramy. Zespoły kurczowo trzymające się DoR, mogą mieć problem z definiowaniem i podejmowaniem tego typu zadań. A są one ważne dla empiryzmu.

Czy jest nam potrzebna Definicja gotowości?

Jedno z założeń Manifestu Agile prawi, by cenić współpracę ponad negocjację umów. I choć punkt ten oryginalnie dotyczy współpracy z klientem, to myślę, że można go również podciągnąć pod funkcjonowanie Zespołu. Jeżeli Zespół dobrze rozumie wspomniane założenie oraz na co dzień pracuje w zgodzie z wartościami Scruma, to korzystanie z Definicji Gotowości nie powinno być problemem. Będą w stanie uniknąć opisanych przez mnie pułapek.

Jednak niedoświadczone Zespoły, mogą mieć więcej trudności z wyłapaniem negatywnych skutków jej stosowania.

Co zatem zrobić, gdy szukamy sposobu na skuteczne zapewnienie odpowiedniej ilości szczegółów w elementach Product Backlogu?

Uważnie przyjrzyjmy się procesowi doskonalenia Product Backlogu, czyli Refinementom.

Definicja Gotowości jako drogowskaz podczas Refinementów

Jeżeli celem naszych działań jest zwiększenie jakości PBI, to narzędziem proponowanym przez Scrum Guide jest Refinement, czyli Doskonalenie Product Backlogu. Są to spotkania, które regularnie odbywają się w trakcie trwania Sprintów. Mają na celu przygotowanie szczegółów elementów znajdujących się na szczycie Product Backlogu.

W trakcie Refinementów można użyć listy, podobnej do Definicji Gotowości, która wskaże nam kiedy PBI jest zrozumiały dla każdego członka Zespołu oraz ma wystarczająco dużo szczegółów, by uznać go za gotowego.

Określenie tego co jest istotne do ustalenia w PBI, by płynnie przejść przez jego realizację bez potykania się o potencjalne braki w opisie jest dobrym pomysłem [2]. Taka lista kontrolna powinna być jednak podstawą do rozmów i współpracy w Zespole.

A gdyby tak zamiast nazywać tę listę Definicją Gotowości (która zawsze może nas niefortunnie sprowadzić na złe tory), zrezygnować z jej nazywania? Lub nazwać ją „Polityką Refinementów”? Byłoby to narzędzie pomagające upewnić się, że o niczym nie zapomnieliśmy w trakcie opracowywania PBI. Regularne korzystanie z listy wyrobi nawyk, który z biegiem czasu wykluczy konieczność korzystania z checklisty. Będziemy zwyczajnie mieć w Zespole wspólne rozumienie czym jest gotowy PBI.

Jak to może działać w praktyce?

Podczas Refinementow, PBI spełniające wcześniejsze ustalenia mogą zmieniać status np. z New na Approved. Dzięki temu, podczas Planowania jasno widać, które z elementów Backlogu są gotowe do realizacji.

Jeżeli na Planowaniu napotykamy na element ze szczytu Backlogu ze statusem New, wiadomo wtedy, że wymaga on dodatkowej rozmowy. Jeżeli zidentyfikujemy brakujące szczegóły, możemy je doprecyzować w trakcie trwania wydarzenia lub zaplanować zdobycie koniecznych szczegółów jako pierwsze zadania w Sprincie (np. uzupełnić brakujące teksty dla użytkownika lub makiety UI).

Podsumowanie

Definicja Gotowości jest praktyką często wykorzystywaną przez Zespoły pracujące w Scrumie. I choć zamysł jej wykorzystania wydaje się prosty i bezproblemowy, to w istocie może ona przynieść więcej złego niż dobrego. Źle wykorzystana może pogłębiać problemy, na które miała być rozwiązaniem. Może ona utrudniać współpracę, tworząc bariery między członkami Zespołu. Zatem zanim zdecydujesz się na korzystanie z tej praktyki, zastanów się co próbujesz osiągnąć. Być może okaże się, że Definicja Gotowości nie jest Ci potrzebna, a jedyne co trzeba usprawnić to proces Refinementów.  

Bibliografia

[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

[2] Why isn’t the Definition of Ready described in the Scrum Guide?; https://www.scrum.org/resources/blog/why-isnt-definition-ready-described-scrum-guide

[3] YDS: What is the Definition of Ready in Scrum?; https://www.youtube.com/watch?v=DDiiFnNQjYk&t=476s

[4] Definition of Ready – blaski i cienie; https://marcinfliszta.pl/definition-of-ready-blaski-i-cienie/

[5] Definition of Ready; https://porzadnyagile.pl/047-definition-of-ready/

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *