Retrospektywa Definition of Ready

Sprawdź, czy historyjki są gotowe, zanim ruszy sprint.

Zapraszamy do obejrzenia tej retrospektywy na żywo

Nasza obecna DoR

Jak dziś wygląda nasza Definition of Ready?

Mówimy, że historyjka jest gotowa, gdy ma kryteria akceptacji, ale nie sądzę, żebyśmy wszyscy zgadzali się co do tego, jak wyglądają „dobre” kryteria akceptacji.
Nasza DoR obejmuje: spisaną historyjkę użytkownika, zdefiniowane kryteria akceptacji, wycenę w punktach i zidentyfikowane zależności.
Szczerze mówiąc, nie jestem pewien, czy w ogóle mamy formalną DoR. Po prostu bierzemy to, co jest na górze backlogu.
Kiedy to działa

Co idzie dobrze, gdy historyjki spełniają naszą DoR?

Kiedy historyjki są dobrze oszacowane i mają jasne kryteria akceptacji, planowanie sprintu idzie dużo szybciej. Kończymy w niecałą godzinę.
Zauważam, że mamy dużo mniej blokerów w trakcie sprintu, gdy zależności zostają wskazane od razu na refinemencie.
Zespół czuje się pewniej, biorąc historyjki do sprintu, kiedy każdy miał okazję zadać pytania przed jego startem.
Kiedy to zawodzi

Jakie problemy pojawiają się, gdy historyjki nie są naprawdę gotowe?

W zeszłym sprincie wzięliśmy historyjkę bez kryteriów akceptacji i skończyło się na trzech dniach przerzucania się pytaniami z PO.
Historyjki bez jasnego zakresu każdy deweloper „kończy” po swojemu, a potem QA znajduje niespójności.
Ciągle odkrywamy w połowie sprintu zależności, które blokują nas na całe dni. To powinno wyjść na refinemencie.
Ulepszmy naszą DoR

Co zmienić, żeby wzmocnić naszą Definition of Ready?

Powinniśmy dodać checklistę do szablonu zgłoszenia w Jirze, żeby nic nie umknęło, zanim historyjka zostanie oznaczona jako gotowa.
Chciałbym, żebyśmy ustalili, że żadna historyjka nie wchodzi do sprintu bez co najmniej jednego refinementu z udziałem całego zespołu.
Potrzebujemy jasnej zasady: jeśli historyjka nie ma kryteriów akceptacji na 48 godzin przed planowaniem, nie planujemy jej.

Czym jest retrospektywa Definition of Ready?

Sprint przebiega lepiej, gdy praca, która do niego trafia, była gotowa jeszcze przed planowaniem. Definition of Ready (DoR, definicja gotowości) to lista kryteriów wejścia, które element backlogu musi spełnić, zanim zespół weźmie go do sprintu, np. kryteria akceptacji, estymata i znane zależności. Retrospektywa Definition of Ready sprawdza, czy ta lista spełnia swoje zadanie. Tablica ma cztery kolumny. W kolumnie Nasza obecna DoR zapisujecie, jakie kryteria faktycznie obowiązują dziś. Często okazuje się przy tym, że każdy rozumie je inaczej. Kiedy to działa zbiera przykłady gotowych historyjek, które poszły gładko. Kiedy to zawodzi dotyczy sytuacji, w których do sprintu trafiła niegotowa praca. W kolumnie Ulepszmy naszą DoR uzgadniacie zmiany. Skorzystaj z tego formatu, gdy planowanie ciągle się przeciąga, historyjki utykają w połowie sprintu albo nikt nie zaglądał do waszej DoR od miesięcy. Sprawdza się zarówno w zespołach scrumowych, jak i kanbanowych. W TeamRetro można dodawać pomysły anonimowo, więc problemy z refinementem wychodzą na jaw nawet wtedy, gdy niezręcznie o nich mówić.

Format retrospektywy Definition of Ready

Nasza obecna DoR

Jak dziś wygląda nasza Definition of Ready?

Poproś wszystkich, żeby zapisali, jakie ich zdaniem są obecne kryteria. Wiele zespołów ma nieformalną lub niespisaną DoR, a różnice między odpowiedziami pokażą wam, od czego zacząć.

Kiedy to działa

Co idzie dobrze, gdy historyjki spełniają naszą DoR?

Szukajcie konkretnych sprintów lub historyjek, w których gotowość zrobiła różnicę, np. krótkie planowanie albo historyjka skończona bez ganiania kogokolwiek. Takie przykłady pokazują zespołowi, dlaczego warto dbać o DoR.

Kiedy to zawodzi

Jakie problemy pojawiają się, gdy historyjki nie są naprawdę gotowe?

Ta kolumna zwykle mówi najwięcej. Poproś o konkretne historyjki, które weszły do sprintu bez spełnienia DoR, i o to, co działo się dalej. Szukajcie wzorców: czy wciąż wracają te same braki albo czy dotyczą tych samych rodzajów historyjek?

Ulepszmy naszą DoR

Co zmienić, żeby wzmocnić naszą Definition of Ready?

Uzgodnijcie konkretne zmiany, np. dodanie lub usunięcie kryteriów, zmianę sposobu prowadzenia refinementu albo dostosowanie narzędzi. Celem jest wyjście ze spotkania z 1–3 zmianami do przetestowania w następnym sprincie.

Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego

  • Zespół ciągle trafia na blokery w trakcie sprintu, rozrost zakresu albo historyjki, których nie da się skończyć w sprincie, co często oznacza, że praca nie była gotowa w momencie planowania.
  • Planowanie sprintu się przeciąga albo jest chaotyczne, bo backlog nie przeszedł refinementu, zanim zespół się zobowiązał.
  • Wdrażacie nowe osoby i chcecie spisać, co „gotowe” oznacza w waszym zespole.
  • Zespół ma Definition of Ready, ale od dawna jej nie przeglądał i może ona nie odpowiadać temu, jak pracujecie teraz.
  • Po trudnym sprincie, w którym niejasne wymagania lub brakujące informacje spowodowały opóźnienia albo poprawki.

Proponowane pytania lodołamacze

  • Gdyby wasz backlog był kuchnią, byłby dobrze zaopatrzoną, uporządkowaną spiżarnią czy chaotyczną lodówką pełną tajemniczych resztek? Dlaczego?
  • Jaka jedna rzecz, o której chcielibyście wiedzieć na starcie zadania, zawsze wychodzi na jaw dopiero w połowie?

Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →

Pomysły i wskazówki dotyczące spotkania retrospektywnego

  • Udostępnij obecną DoR przed spotkaniem, żeby uczestnicy przyszli z prawdziwymi przykładami.
  • Rozmawiajcie o lukach w procesie, a nie o błędach konkretnych osób, żeby każdy mógł opisać, co poszło nie tak, bez szukania winnych.
  • Ustal limit czasu dla każdej kolumny. Dyskusje o DoR łatwo zamieniają się w refinement pojedynczych historyjek, więc trzymaj retrospektywę przy samych kryteriach.
  • Uzgadniajcie 1–3 zmiany na spotkanie. DoR, która próbuje objąć wszystko, robi się zbyt długa, żeby dało się jej przestrzegać.
  • Zaangażuj cały zespół, nie tylko Scrum Mastera czy Product Ownera. Deweloperzy, QA i projektanci każdy na swój sposób odczuwają skutki niegotowych historyjek.
  • Na następnej retrospektywie sprawdźcie, czy zmiany ułatwiły planowanie i dostarczanie.

Najczęściej zadawane pytania

Czym jest retrospektywa Definition of Ready?
To retrospektywa, podczas której zespół przegląda swoje kryteria wejścia dla elementów backlogu. Tablica obejmuje obecną DoR, to, co działa, gdy historyjki ją spełniają, co zawodzi, gdy jej nie spełniają, oraz to, co warto zmienić.
Czym różni się Definition of Ready od Definition of Done?
Definition of Ready określa kryteria wejścia, które element backlogu musi spełnić, zanim trafi do sprintu. Definition of Done określa kryteria wyjścia, czyli kiedy praca jest ukończona. Ta retrospektywa dotyczy tej pierwszej.
Jak często zespół powinien przeprowadzać retrospektywę Definition of Ready?
Przeprowadź ją po trudnym sprincie z niejasnymi wymaganiami, gdy dołączają nowe osoby, albo co kilka miesięcy, żeby sprawdzić, czy DoR wciąż odpowiada temu, jak pracuje zespół.
Czy Definition of Ready jest częścią Scruma?
Nie. Scrum Guide definiuje Definition of Done, ale nie Definition of Ready, którą wiele zespołów scrumowych dodaje samodzielnie. Niech będzie lekka, żeby nie stała się bramką blokującą wartościową pracę.
Ile trwa retrospektywa Definition of Ready?
W większości zespołów od 45 do 60 minut. Trzymajcie dyskusję przy samych kryteriach, bo inaczej zamieni się w refinement.

Powiązane szablony

Retrospektywa WWE Smackdown Showdown

Podsumujcie sprint w duchu wrestlingu, ramię w ramię.

Retrospektywa Sherlocka

Zbadaj ostatni sprint jak prawdziwy detektyw.

Retrospektywa Szkieletowa Ekipa

Wyciągnijcie wnioski z tygodni pracy w okrojonym składzie.

Retrospektywa Podróżnika w Czasie

Spójrzcie wstecz, oceńcie teraźniejszość i zaplanujcie przyszłość w jednej retrospektywie

Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo