Definicja

Definition of Ready (Definicja Gotowości) to umowa między zespołem deweloperskim a Product Ownerem, określająca, jakie informacje i warunki muszą zostać spełnione, aby zadanie (User Story) było “gotowe” do pracy. DoR działa jak filtr jakościowy, który zapobiega rozpoczynaniu zadań niejasnych, zbyt dużych lub niedoprecyzowanych, co mogłoby blokować pracę zespołu w trakcie sprintu.

Po co stosujemy DoR?

Głównym celem Definition of Ready jest zminimalizowanie ryzyka przestojów. Jeśli zespół bierze do sprintu zadanie, które nie jest “Ready”, często w połowie pracy okazuje się, że brakuje kluczowych wymagań, dostępów lub makiety, co prowadzi do niewykonania celu sprintu.

Przykładowe kryteria Definition of Ready

Standardowa lista DoR może zawierać następujące punkty:

- User Story jest opisane zgodnie z szablonem (Jako... Chcę... Aby...).
- Kryteria Akceptacji (AC) są jasno zdefiniowane i zrozumiałe dla zespołu.
- Zależności zewnętrzne są zidentyfikowane i rozwiązane.
- Wymagania niefunkcjonalne (np. wydajność, bezpieczeństwo) są określone.
- Makiety/projekty UI są gotowe i dołączone do zadania (jeśli dotyczy).
- Wielkość zadania została oszacowana (np. w Story Points) i jest na tyle mała, by zmieścić się w jednym sprincie.
- Zespół potwierdza, że rozumie cel zadania i wie, jak je zrealizować.

DoR a Model INVEST

Przy tworzeniu Definition of Ready często korzysta się z akronimu INVEST, który określa cechy dobrego elementu backlogu:

- Independent (Niezależny).
- Negotiable (Negocjowalny).
- Valuable (Wartościowy).
- Estimable (Możliwy do oszacowania).
- Small (Mały).
- Testable (Testowalny).

Różnica między DoR a DoD

Częstym błędem jest mylenie Definition of Ready z Definition of Done (DoD).

Cecha Definition of Ready (DoR) Definition of Done (DoD)
Kiedy? Przed rozpoczęciem pracy (na wejściu). Po zakończeniu pracy (na wyjściu).
Cel Sprawdzenie, czy zadanie jest zrozumiałe i wykonalne. Sprawdzenie, czy przyrost spełnia standardy jakości.
Kto dba? Głównie Product Owner we współpracy z zespołem. Zespół Deweloperski.

Typowe błędy

❌ Zbyt rygorystyczny DoR – Tworzenie bariery biurokratycznej, która przypomina tradycyjną specyfikację i blokuje start prac. ❌ DoR jako “kontrakt” – Brak rozmowy (Conversation) i ślepe trzymanie się checklisty bez zrozumienia kontekstu. ❌ Brak aktualizacji – DoR, który nie ewoluuje wraz z rozwojem zespołu i projektu. ❌ Ignorowanie DoR podczas planowania – Włączanie do sprintu zadań “na słowo”, które nie spełniają żadnych kryteriów gotowości.

Podsumowanie

Definition of Ready to potężne narzędzie wspierające Backlog Refinement. Pozwala ono na “wyostrzenie” wymagań, zanim trafią one do realizacji, co bezpośrednio przekłada się na przewidywalność zespołu i płynność pracy w sprincie.

Powiązane pojęcia:

Kliknij w pojęcie, aby przejść do jego definicji w słowniku