Od czasu do czasu w dyskusjach o Scrumie i związanych z nim praktykach przewija się temat Definicji gotowości (ang. definition of ready). Niektórzy niesłusznie uważają, że jest ona częścią tej metody, inni są przekonani, że choć nie jest elementem Scruma, ułatwia pielęgnację Backlogu Produktu i ma pozytywny wpływ na jego kondycję. Tymczasem, jak każda praktyka, tak i definicja gotowości bywa pomocna, o ile potrafimy posłużyć się nią świadomie i poprawnie.

Czym jest definition of ready

Narzędzie to jest niezwykle proste: Zespół określa kryteria, jakie powinny spełniać elementy Backlogu Produktu, aby można uznać je za gotowe do realizacji. Przykład definition of ready wygląda tak:

  • Wymaganie zapisane jako historyjka użytkownika (user story).
  • Wymaganie zostało oszacowane metodą przyjętą przez Zespół.
  • Wymaganie jest dostatecznie małe, by zmieścić się w Sprincie (często po prostu określona jest maksymalna wielkość oszacowania, powyżej którego wymaganie należy dekomponować na kilka mniejszych).
  • Zdefiniowane zostały kryteria akceptacyjne wymagania.

Tak określonej definicji gotowości Zespół może użyć podczas pielęgnacji Backlogu Produktu do oceny, czy jego poszczególne elementy wymagają dalszego doprecyzowania lub dekompozycji, czy też można rozpocząć planowanie ich realizacji w jednym z nadchodzących Sprintów.

Proste, ułatwia pracę, nieszkodliwe, prawda? Być może.

Jak definiuje to Scrum Guide

W definicji metody nie ma ani słowa o definition of ready, a mowa jest jedynie o stanie gotowości (ang. ready), w jakim powinny znaleźć się elementy Backlogu Produktu, aby możliwe było zaplanowanie ich realizacji. Twórcy Scruma nie podają szczegółowej listy kryteriów.

Czym ów stan gotowości jest w praktyce? Skoro ma być możliwe zaplanowanie prac nad elementem Backlogu, musi być on dostatecznie mały, by Developerzy mogli zrealizować go w Sprincie i by nie był to jedyny element podjęty do realizacji. Co więcej, Zespół musi rozumieć potrzebę lub problem, jaki opisuje element Backlogu Produktu, aby móc po ukończeniu prac stwierdzić, czy udało się tę potrzebę zaspokoić (czy problem został rozwiązany).

Kryteria akceptacyjne, metody szacowania i dekomponowania wymagań, podobnie jak różne formaty zapisu elementów Backlogu – to są praktyki wspierające metodę Scrum. Żadna nich nie jest wskazana jako obowiązkowa bądź rekomendowana. Wybór sposobu, w jaki elementy Backlogu doprowadzone zostaną do stanu gotowości, należy do Zespołu Scrum. Jeśli uzna za zasadne posługiwać się przy tym definition of ready, jest to jak najbardziej poprawne działanie w Scrumie.

Gdy definition of ready ruguje empiryzm z procesu

Doświadczenie wielu Zespołów pokazuje, że definicja gotowości ma duży potencjał do wygenerowania problemów. W skrajnym przypadku ofiarą jej zastosowania może być kluczowy dla zwinności empiryzm.

Często bowiem lista kryteriów, jaka zawarta została w definicji gotowości, prowokuje Zespół do zacierania granicy między pielęgnacją elementów Backlogu Produktu a planowaniem ich realizacji w Sprincie. Dzieje się tak zwłaszcza wtedy, gdy Zespół używa definicji gotowości nie do przygotowania się do Planowania Sprintu, ale do zagwarantowania, że elementy Backlogu Produktu da się zrealizować.

Żeby taką pewność (a w istocie jej złudzenie) osiągnąć, Zespół w ramach pielęgnacji Backlogu Produktu nie ogranicza się do dyskusji o potrzebach i możliwych sposobach ich zaspokojenia. Zaczyna budować od razu plan implementacji zmian w produkcie, nierzadko bardzo szczegółowy. To, co powinno zostać zrobione dopiero w momencie Planowania Sprintu, odbywa się na długo przed nim.

Ba, część Zespołów idzie jeszcze dalej i definiuje od razu szczegółowe zadania developerskie, choć przecież jeszcze nie wiadomo, czy wszystkie elementy znajdujące się aktualnie w Backlogu Produktu będą ostatecznie realizowane. Zdarza się nawet, że zadania takie przypisywane są z góry do konkretnych osób… W takim przypadku Planowanie Sprintu staje się ceremonią bez wartości, bo jeszcze nim się rozpocznie, z góry wiadomo, kto, co i jak będzie robił.

Tak zaplanowany Sprint prawie nigdy nie służy poszukiwaniu dobrych rozwiązań, tylko „dowiezieniu” tego, co już wcześniej w detalach ustalono.

Jak popsuć relacje przy pomocy definition of ready

Mniej skrajnym, ale nadal bardzo dotkliwym skutkiem negatywnym używania definicji gotowości, jest popsucie relacji pomiędzy Product Ownerem a Developerami. Może dojść do tego na kilka sposobów.

Jeśli Developerzy z jakiegoś powodu nie chcą podjąć do realizacji konkretnego wymagania, mogą wykorzystać pretekst, jakim jest niespełnienie jednego z wymogów definicji gotowości. Przykładowo, Product Owner chce zmienić kolor przycisku u dołu jakiegoś formularza internetowego z czerwonego na zielony, a Developerzy mówią mu, że nie mogą tego zrobić, bo zgodnie z definition of ready, „każda zmiana w wyglądzie strony internetowej wymaga przygotowania projektu graficznego”, którego w tym przypadku nie ma.

Skąd może brać się ten brak elastyczności u Developerów? Na przykład z tego, że organizacja zbyt surowo rozlicza Developerów z „niedowiezienia” wszystkiego, co podjęte zostało do realizacji w Sprincie. Albo z presji, by implementowali coraz więcej wymagań w każdej iteracji, choć zaczyna im brakować czasu na dobre przygotowanie się do pracy i zrozumienie, co właściwie mają zrobić.

W oczywisty sposób będą wtedy szukać każdego sposobu, by dokonywać w produkcie tylko takich zmian, z którymi nie wiąże się duża niewiadoma. Być może zmiana koloru przycisku nie jest tak trywialna, jak się wydaje, więc korzystają z okazji, iż formalne wymogi definition of ready nie są zaspokojone.

Psucie relacji może zresztą nastąpić z inicjatywy Product Ownera, który nie przyjmuje do wiadomości, że Developerzy nie są pewni, o co chodzi w jakimś wymaganiu i nie czują, że są w stanie zrealizować go w trakcie Sprintu. Aby postawić na swoim, zażąda wykazania, że choć jeden z zapisów w definicji gotowości nie jest spełniony. A przecież Developerzy mogą nie być w stanie tego zrobić.

Naturalną konsekwencją takiego zdarzenia będzie dążenie przez Developerów do dalszego rozbudowywania definition of ready tak, by w przyszłości mieli podstawę do odmowy realizacji wymagań, której tym razem brakło.

Jeszcze inny scenariusz psucia relacji za pomocą definicji gotowości jest bardzo prosty. Jeśli stosunkowo często okazuje się, że rozwiązania wytworzone przez Developerów muszą być przerabiane (bo np. Przegląd Sprintu ujawni taką potrzebę), Developerzy mogą zacząć domagać się od Product Ownera, by „pisał lepsze wymagania”. O tym, co takie „lepsze wymagania” mają zawierać, rozstrzygać będzie właśnie powoli rozrastające się definition of ready. W ten sposób nieświadomie mogą i siebie i Product Ownera wciągnąć w pułapkę, której efektem będzie okładanie się definicją gotowości po głowach, o którym pisałem powyżej.

Nie jest oczywiście tak, że definition of ready samo z siebie zaczyna psuć relacje, bo przecież są Zespoły, które potrafią go używać bez żadnych negatywnych konsekwencji. Jeśli jednak istnieją jakieś konflikty w Zespole lub obawy poszczególnych jego członków, praktyka zaczyna działać na nie niczym szkło powiększające i sytuacja szybko może z umiarkowanie dobrej stać się naprawdę zła.

A jeśli do tego dojdzie, relacje w Zespole, a czasami i Zespołu z otoczeniem, zaczynają sprowadzać się do licytowania się różnymi listami kryteriów do spełnienia i wzajemne udowadnianie sobie, co ktoś zrobił, a czego nie zrobił i dlaczego. To, czy działający produkt powstanie i będzie wartościowy, schodzi gdzieś na dalszy plan.

Skutki niedojrzałości Product Ownera

Bardzo często definition of ready jest praktyką przyjętą na skutek braku lub niskiego poziomu zaufania między Product Ownerem a Developerami. Nie wierzą oni (i zdarza się, że mają rację), że Product Owner weźmie odpowiedzialność za swe decyzje i są przekonani, że to ich interesariusze oskarżą o zbudowanie niewłaściwego produktu. Sformalizowanie dyskusji o wymaganiach poprzez wprowadzenie listy kontrolnej pozwala w razie czego wykazać Product Ownerowi, że to on zawalił.

Podzielmy wymagania, bo…

…wymaga tego definition of ready. Bo przecież wymaganie jest za duże – zostało oszacowane na 13 punktów, a mamy jasno powiedziane, że największe, jakie realizujemy, to takie na 8 punktów…

Znacie to? Niestety, to kolejna możliwa konsekwencja stosowania definition of ready. Zapisy o maksymalnej dopuszczalnej wielkości oszacowania, o ile się w niej znajdą, prowokują do niepotrzebnych i przedwczesnych dekompozycji elementów Backlogu Produktu. Zamiast każdorazowo podjąć decyzję o podziale w ramach merytorycznej dyskusji o tym, czy da się je zrealizować w Sprint, Zespół zaczyna patrzyć wyłącznie na cyferki wpisane jako estymaty. Zamiera dyskusja o tym, co jest do zrobienia, a zaczyna się dyskusja o samym oszacowaniu.

Jak radzić sobie bez definition of ready

Wystarczy rozmawiać i rozumieć, czym jest każdy Sprint – eksperymentem, w którym nigdy nie ma pewności, że coś da się zrobić. Nie ma też gwarancji, że jak zbudujemy produkt, o jakim mówiliśmy, to nie okaże się, że to nie jest produkt, którego potrzebują interesariusze. I właśnie po to robimy Sprinty maksymalnie miesięczne, aby ograniczać ryzyko, że zbyt długo będziemy robić coś, co nie da wartościowych rezultatów.

Jeśli wymaganie znajduje się na początku listy w Backlogu Produktu i Developerzy ocenią w czasie Planowania Sprintu, że zdołają poradzić sobie z ewentualnymi niewiadomymi i doprecyzowaniem szczegółów już w ramach iteracji, czemu mieliby odmawiać realizacji tego elementu z Backlogu?

A jeśli pozostało kilka pytań bez odpowiedzi lub interesariusze wahają się, jakie rozwiązanie będzie akceptowalne? Być może wtedy również da się poszukać odpowiedzi już w czasie Sprintu i użyć ich do zbudowania działającego produktu. Ba, poszukiwanie odpowiedzi na otwarte pytania będzie wtedy częścią realizacji wymagania, a nie przygotowywaniem się do niej.

Podobnie jest z zależnościami do prac realizowanych przez inne Zespoły: Developerzy mogą uznać, że poradzą sobie z nimi w czasie Sprintu. Takie wymaganie, choć obłożone będzie pewnym ryzykiem, jeśli chodzi o możliwość jego implementacji, jest również w stanie gotowości.

Brak formalnego definition of ready pozwala działać elastycznie, bo Zespół indywidualnie ocenia każdy z elementów Backlogu Produktu. Sformalizowanie warunków gotowości spowoduje natomiast, że zamiast używać Sprintów do zbudowania rozwiązania i sprawdzenia z interesariuszami, czy jest ono właściwe, Zespół zacznie inwestować czas w analizy, które mają zapewnić, że „na pewno” wytworzone zostanie to, co trzeba. Czy to jest jeszcze Scrum? Niekoniecznie…

Używać, czy nie używać definition of ready?

Sama praktyka, jak wszystkie inne, nie jest ani zła, ani dobra. Nie używajmy jej jako przykrywki na już istniejące dysfunkcje. A jeśli dysfunkcji nie ma, pilnujmy się, by ich nie spowodowała.

W mojej ocenie, choć podkreślam mocno, że to wyłącznie moja ocena, definition of ready jest jedną z takich praktyk, które niosą spory potencjał kreowania problemów w dobrze działającym Scrumie. Niby opiera się na porozumieniu, umowie co do kryteriów gotowości wymagań, ale ciężko pogodzić elastyczność i otwartość na zmiany z jakimkolwiek formalizmem. Niby zapewnia przejrzystość i ma ułatwiać dbanie o Backlog Produktu, ale z drugiej strony każda naprawdę sensowna lista kryteriów jest na tyle krótka i oczywista, że jej spisywanie w formie jakieś definicji nie wydaje się potrzebne. Więc po co to robić?

A jeśli jednak zdecydujemy się użyć definicji gotowości, upewnijmy się przy okazji, że nikt nie pomyli jej z obowiązkową w Scrumie Definicją Ukończenia (ang. Definition of Done), bo i to się zdarza.