Do tej pory nie było na naszym blogu tekstu o Definition of Ready. Niedopatrzenie czy celowe działanie? Wszystko wyjaśnimy w dzisiejszym tekście…
Definition of Ready
Pierwszy raz z Definition of Ready spotkaliśmy się na naszym blogu przy okazji tematu pod tytułem Product Backlog Refinement. Wspominaliśmy tam, że nasz tytułowy bohater jest bramką, która powstrzymuje nas przed wzięciem na planowanie zbyt dużych tematów. Tylko tyle i aż tyle. Przypomnijmy cytat ze Scrum Guide’a:
“Elementy Backlogu Produktu, które mogą zostać „Ukończone” przez Zespół Deweloperski w pojedynczym Sprincie, uznawane są za „Przygotowane” do rozważenia podczas Planowania Sprintu.” – Scrum Guide
Daleko co prawda od tego cytatu do formalnego Definition of Ready, ale wyraźnie jest tu podkreślone, że nie wszystkie wymagania nadają się do rozważenia podczas Sprint Planningu. Zwracam tu szczególną uwagę na słowo „rozważyć”, które jasno pokazuje nam że niektórymi wymaganiami nie powinniśmy nawet zaprzątać sobie głowy!
W myśl podręcznika kryterium jest jedno – czy wymaganie ma szansę być ukończone w jednym Sprincie. Mówiąc wprost, nasze Definition of Ready powinno określać nam, czy jesteśmy w stanie zrealizować dane wymaganie od A do Z w dostępnym nam czasie jednej iteracji. Jeżeli nie, pomijamy taki PBI na planowaniu i po prostu przechodzimy do następnych.
Powyższe znaczy też, że cały zespół powinien wiedzieć co to znaczy „od A do Z”. Dla niektórych zespołów jest to jednak za mało i rozszerzają one definicję tego, czym według nich jest „przygotowane wymaganie”. Tak narodził się DoR.
DoR, czyli drzwi
Definition of Done nazywane bywa pieszczotliwie DoDą. Definition of Ready dla odmiany aż się prosi o to, żeby nazywać je Do(o)R.
Nasze „drzwi” to lista kryteriów, które musi spełnić każde wymaganie, abyśmy w ogóle wzięli je pod uwagę. To powoduje, że mamy tak naprawdę dwie listy wymagań – te gotowe, czyli backlog oraz te niegotowe, czyli poczekalnię.
Definition of Ready mówi nam, kiedy wymagania mogą trafić z poczekalni do backlogu. Oczywiście praca związana z potwierdzeniem tych kryteriów, a także samym przeniesieniem do backlogu właściwego odbywa się na Product Backlog Refinement.
Kto zarządza „ready”? Cały zespół. To zespół musi stwierdzić, że rozumie wymaganie i że jest ono odpowiednio szczegółowo opisane. Wszyscy razem i każdy z osobna powinien potwierdzić, „rozumiemy co jest do zrobienia i damy radę to zrobić w jednym Sprincie”. Zanim przejdziemy do tego, jakie mogą być te kryteria, zatrzymajmy się przy odpowiedzialności.
Nie da się ukryć, że cała ta koncepcja jest bardzo silnym narzędziem. Definition of Ready pozbawia Product Ownera pełni władzy nad backlogiem. To już nie jest tak, że to PO decyduje o tym, co będziemy robili w pierwszej kolejności, ale robi to cały zespół. Bo nawet jeśli PO wrzuci coś na szczyt backlogu, to nawet na to nie spojrzymy, jeżeli nie jest „Ready”.
Problemy z Definition of Ready
Pół biedy, jeżeli nasze Definition of Ready składa się z jednego punktu, który mówi „cały zespół potwierdził, że wymaganie jest zrabialne w jednym Sprincie”. Niestety, często ta lista kryteriów będzie rozbudowana. A to jest problem.
Po pierwsze, DoR jest oznaką braku zaufania. Wprowadzając rozbudowane Definition of Ready mówimy wprost „nasz Product Owner wrzuca nam wymagania, o których nie mamy pojęcia i to jest jedyny sposób, żeby go przed tym powstrzymać”.
Problem z niezrozumiałymi wymaganiami powinniśmy rozwiązać współpracą z Product Ownerem. Droga do sukcesu na pewno nie jest usłana dodatkowymi bramkami i regułami. W końcu „ludzie i relacje ponad procesy i narzędzia”. Dlatego zawsze troszeczkę mnie boli, gdy ludzie zamiast ze sobą rozmawiać chcą wprowadzić jakieś narzędzia, reguły, procedury i dupokrytki.
Powinno być dobrym zwyczajem, że zanim wymaganie trafi na planowanie, jest ono omówione na refinemencie, a zespół rozwiewa wszelkie wątpliwości. Jeżeli jakieś niejasności pozostały, PO nie powinien nalegać na realizację danego wymagania w najbliższym Sprincie. Co prawda takie podejście może doprowadzić do sytuacji, w której podyskutujemy na Planowaniu o tym, czemu czegoś nie bierzemy, ale nie jest to przecież jakiś wielki problem.
Wady i zalety Definition of Ready
Jak się możecie domyślać, nie jestem wielkim zwolennikiem Definition of Ready. Wydaje mi się, że cały zwinny proces pracy nad wymaganiami powinien być naturalny dla wszystkich. Nikt nie powinien forsować wykonywania rzeczy, o których nie mamy pojęcia. Jeżeli tak jest, znajdźmy źródło problemu a nie próbujmy maskować go konstrukcjami w rodzaju DoR. To trochę tak jak z DoDą.
Definition of Done nie powinno być kagańcem nakładanym na nas przez organizację, po to abyśmy „nie oddawali chłamu”. DoDa jest po to, żebyśmy my sami przypadkiem nie zapomnieli o czymś, na co się umówiliśmy i co obiecaliśmy. Możemy w ten sam sposób potraktować DoR.
Jeżeli już naprawdę potrzebujemy listy cech, które wymaganie powinno spełniać, żebyśmy w ogóle je rozważali na planowaniu, to upewnijmy się że ta lista obrazuje nasze wewnętrzne potrzeby. Mówiąc innymi słowami, nie chcemy blokować Product Ownera, tylko sami dla siebie chcemy wprowadzić pewne kryteria żeby pracować lepiej. Takie Definition of Ready na pewno będzie małe zwarte i przydatne.
Ale to już do was należy decyzja czy potrzebujecie w Definition of Ready zawrzeć coś więcej niż „zrozumiałe i mieszczące się w Sprincie”.
