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

Czym jest Definition of Ready

Koncept jest niezwykle prosty: zespół scrumowy określa kryteria, jakie powinny spełniać elementy backlogu produktu aby można uznać je za gotowe do podjęcia do realizacji. Przykładowe Definition of Ready wygląda tak:

  • Wymaganie zapisane jako historyjka użytkownika (User Story).
  • Wymaganie zostało oszacowane (określona została jego czasochłonność lub pracochłonność metodą przyjętą przez zespół developerski).
  • 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.

Dzięki tak określonym kryteriom zespół wie podczas pielęgnacji backlogu produktu czy poszczególne elementy tego backlogu wymagają dalszego doprecyzowania lub dekompozycji, czy też można rozpocząć planowanie ich realizacji w jednym z nadchodzących sprintów.

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

Jak definiuje to Scrum Guide

W definicji metody nie ma ani słowa o Definition of Ready, a jedynie o stanie gotowości (ready state), w jakim powinny znaleźć się elementy na szczycie 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 na elementem backlogu, musi być on dostatecznie mały, by zespół developerski mógł 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 ten element backlogu produktu tak, 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 scrumowego. 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

Praktyka pokazuje, że użyte w dobrej wierze narzędzie potrafi z czasem zaburzyć działanie Scruma i popsuć relacje między developerami i Product Ownerem. Niestety, ofiarą zastosowania Definition of Ready może stać się kluczowy dla zwinności empiryzm.

Często bowiem lista kryteriów, jakie element backlogu musi spełnić przed podjęciem do realizacji jest sformułowana tak, że zespół nie podejmuje w sprincie żadnych tematów, co do których nie ma niemal stuprocentowej pewności, że da się je zrealizować. Żeby taką pewność osiągnąć, najczęściej pielęgnacja backlogu nie zatrzymuje się na etapie określenia potrzeb i sposobu sprawdzenia, że są one zaspokojone, ale praca kontynuowana jest do momentu, aż dla każdego wymagania doprecyzowane zostanie jak ma zostać ono zrealizowane.

Ba, część zespołów idzie jeszcze dalej i tworzy zadania do wykonania przez developerów (choć przecież jeszcze nie wiadomo, czy element backogu produktu w ogóle kiedykolwiek będzie realizowany). Zdarza się że przypisane są one z góry do konkretnych osób… W takim przypadku planowanie sprintu staje się ceremonią bez wartości, bo 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 dotkliwym problemem, wciąż wszakże ciężką dysfunkcją, jest używanie Definition of Ready jako uzasadnienia, że jakieś wymaganie nie może zostać podjęte do sprintu, bo nie spełnia ustalonych kryteriów gotowości. I nieważne, że temat jest krytyczny dla biznesu i Product Ownera, jeśli Definition of Ready mówi, że element backlogu nie nadaje się do realizacji, to realizować go nie można… Co wtedy? Przeskakujemy go na planowaniu sprintu i przechodzimy do kolejnego elementu? Czy też Product Owner jest zmuszony przesunąć ten element w dół?

Jeśli organizacja karze developerów za „niedowiezienie” rzeczy w sprincie, lub choćby źle postrzegane jest, gdy zespół nie ukończy wszystkich wymagań z prognozy sprintu, Definition of Ready zaczyna funkcjonować jako „bramka kontrolna” zabezpieczająca developerów przed podejmowaniem prac, które obciążone są dużą dozą niepewności. Spada elastyczność, i zaczynamy działać w świecie zobowiązań, „kontraktów” między developerami a biznesem – to już nie jest Agile.

Podobnie jeśli w czasie sprintu często okazuje się, że realizacja wymagania zmusza do zmiany pierwotnej koncepcji i utrudnia to pracę developerom, do Definition of Ready zaczynają wpełzać kolejne, coraz bardziej restrykcyjne warunki, które mają temu zapobiec. Powoli zaczyna robić się z tego proces ciężkiej analizy, którą poprzedzona jest praca nad każdym wymaganiem. Zamiast Agile mamy w końcu piękną, choć ukrytą pod nowymi nazwami kaskadę.

A jeśli biznes często mówi na przeglądach sprintu, że „niezupełnie o to chodziło”, to Definition of Ready zaczyna obejmować podpisanie się krwią przez Product Ownera, że tym razem wymagania się nie zmienią. I zamiast backlogu produktu zaczynamy mieć specyfikację produktu, zupełnie jak za starych czasów, od których chcieliśmy odejść zaczynając pracę w Scrumie.

Natomiast najbardziej dotkliwym skutkiem, który może się pojawić, jest zredukowanie relacji między biznesem, zespołem developerskim i Product Ownerem do przepychania się różnego rodzaju listami kryteriów i udowadniania sobie wzajemnie, co kto zrobił, a czego nie zrobił i dlaczego. To, czy produkt jest czegokolwiek wart, schodzi na dalszy plan.

Pochodna braku zaufania lub obaw

Bardzo często Definition of Ready jest praktyką przyjętą na skutek braku zaufania między Product Ownerem a zespołem developerskim. Zespół nie wierzy, że Product Owner weźmie odpowiedzialność za swe decyzje i developerzy nie będą oskarżani przez biznes o złe zrozumienie wymagań. Sformalizowanie dyskusji o wymaganiach poprzez wprowadzenie listy kontrolnej tego, co należy „dostarczyć” w opisie tych wymagań pozwala, w razie czego, wykazać Product Ownerowi, że to on zawalił.

Podzielmy wymagania, bo…

…bo wymaga tego Definition of Ready. Bo przecież wymaganie jest za duże – ma 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 prowokują do niepotrzebnych dekompozycji elementów backlogu. Zamiast każdorazowo podjąć decyzję o podziale poprzez merytoryczną dyskusję o tym, czy da się je zrealizować w sprint, zaczynamy 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 potrzebujemy. 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 jest na górze backlogu produktu i zespół oceni w czasie planowania, że zdoła poradzić sobie z niewiadomymi i doprecyzowaniem go już w czasie realizacji, czemuż miałby odmawiać realizacji tego elementu z backlogu?

Jeśli na przykład mamy zbudować interfejs użytkownika (UI) a brak makiety z jego projektem, to czy wymaganie jest gotowe do realizacji? Tak, jeśli da się opracować projekt UI i wykonać go w czasie sprintu. Wytworzenie niezbędnych makiet stanie się po prostu jednym z zadań do wykonania w ramach developmentu.

A jeśli pozostało kilka pytań bez odpowiedzi, lub biznes waha się, jakie rozwiązanie będzie akceptowalne? Jeśli można znaleźć niezbędne odpowiedzi w czasie sprintu i użyć ich do zbudowania działającego produktu, wymaganie jest w stanie gotowości.

Podobnie jest z zależnościami: może istnieć zależność od prac realizowanych przez inny zespół, której być nie uda się łatwo wyeliminować podczas realizacji wymagania, ale zespół może uznać, że poradzi sobie z tym w czasie sprintu i zaplanuje, jak to zrobić. Takie wymaganie jest zatem również w stanie gotowości.

Brak formalnego Definition of Ready pozwala działać elastycznie. Bo gdyby była lista mówiąca, że każde wymaganie ma mieć projekt UI, nie może mieć zależności, a wszystkie pytania jakie zadano w czasie pielęgnacji backlogu muszą doczekać się odpowiedzi, w żadnym z opisanych powyżej przykładów zespół nie podjąłby realizacji wymagań. Czy byłby to jeszcze Scrum?

Używać, czy nie używać Definition of Ready?

Sama praktyka, jak wszystkie inne, jest neutralna. 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 sensowna lista kryteriów jest na tyle krótka i oczywista, że jej spisywanie w formie jakieś definicji nie wydaje się uzasadnione.