Planning, 11:20. Deweloper otwiera story o integracji z bramką płatności i pyta: "a co się dzieje, jak provider zwróci timeout?". Cisza. Product Owner patrzy na analityka, analityk na notatki, w notatkach nic. Story i tak wchodzi do sprintu, bo "doprecyzujemy w trakcie". Trzy dni później zespół stoi, bo bez odpowiedzi nie da się skończyć implementacji, a osoba po stronie providera wróci z urlopu w poniedziałek.
Ten sprint nie wykoleił się w trakcie. Wykoleił się na planowaniu, w momencie, w którym nikt nie zapytał: "czy ta story w ogóle jest gotowa, żeby ją brać?". Dokładnie od tego są Definition of Ready i Definition of Done. Pokażę Ci, jak je napisać tak, żeby zespół faktycznie ich używał, i dam gotowe checklisty do adaptacji.
DoR vs DoD vs kryteria akceptacji - trzy różne bramki
Te trzy pojęcia mieszają się notorycznie, a odpowiadają na trzy różne pytania:
- Definition of Ready (DoR) - czy story jest gotowa, żeby zespół mógł ją WZIĄĆ do sprintu? Bramka na wejściu. Dotyczy jakości przygotowania: opis, kryteria akceptacji, zależności, wycena.
- Kryteria akceptacji - czy TA KONKRETNA story robi to, co miała robić? Są inne dla każdej story ("po 3 nieudanych próbach logowania konto blokuje się na 15 minut"). W BABOK to technika Acceptance and Evaluation Criteria - kryteria muszą być testowalne, inaczej są ozdobą.
- Definition of Done (DoD) - czy story jest skończona wg wspólnego standardu jakości? Bramka na wyjściu, JEDNA dla wszystkich stories: testy, code review, dokumentacja, deploy.
Dla story z otwarcia tego tekstu testowalne kryterium wyglądałoby tak: "Given bramka płatności zwraca timeout, When klient potwierdza płatność, Then zamówienie dostaje status 'oczekuje na potwierdzenie', klient widzi komunikat o weryfikacji płatności, a system ponawia odpytanie providera co 5 minut przez godzinę". Gdyby to zdanie istniało przed planowaniem, pytanie dewelopera miałoby odpowiedź, zanim padło.
Najprostszy test na rozróżnienie: kryteria akceptacji zmieniają się z każdą story, DoD nie. DoR sprawdzasz przed sprintem, DoD przed powiedzeniem "zrobione".
Jeszcze jedna rzecz, o której mało kto mówi głośno: DoD jest formalnym zobowiązaniem w Scrumie (Scrum Guide wprost go wymaga), a DoR w Scrum Guide nie występuje. To praktyka wypracowana przez zespoły, bo działa. I właśnie dlatego DoR musi być lekki - nie ma za sobą "bo tak każe framework", ma za sobą tylko własną użyteczność.
Czym kończy się sprint bez DoR (typowy scenariusz z planowania)
Znasz ten przebieg, bo widziałeś go nie raz:
- Na planowaniu story ma tytuł i dwa zdania opisu. Zespół wycenia "na oko" - wychodzi 5 SP, bo nikt nie chce drążyć o 15:50 w piątek.
- Deweloper zaczyna pracę i po dniu odkrywa, że story dotyka trzech systemów, a dostęp do jednego z nich wymaga zgłoszenia do innego zespołu.
- Analityk dostaje pytania w trybie pilnym i doprecyzowuje wymagania "na żywo", na Slacku, między innymi zadaniami. Część odpowiedzi ląduje w wątku, część w niczyjej głowie.
- Tester dostaje story ostatniego dnia sprintu i testuje przeciwko kryteriom, które właśnie powstały. Znajduje rozjazd z tym, co zakodowano.
- Story przechodzi do następnego sprintu jako "prawie skończona". Prawie.
Koszt nie jest abstrakcyjny: przełączanie kontekstu u trzech osób, wycena, która nic nie znaczy, i burndown, który wygląda jak EKG. A najgorsze jest to, że zespół uczy się, że planowanie to teatr - i przestaje traktować je poważnie.
DoR nie zrobi z projektu przewidywalnej maszyny. Wyłapuje za to pytania, na które odpowiedź dało się zdobyć przed sprintem - a takich, jak w scenariuszu wyżej, jest większość.
Jak napisać Definition of Ready, którego zespół faktycznie używa
Widziałem DoR-y na 18 punktów. Nikt ich nie sprawdzał, bo nikt nie chce przechodzić 18-punktowej checklisty per story. Zasady, które działają:
Maksymalnie 6-7 punktów. Jeśli masz więcej, część z nich to pobożne życzenia zamiast bramki.
Każdy punkt weryfikowalny w 10 sekund. "Story jest dobrze opisana" nie nadaje się na punkt DoR, bo o "dobrze" można dyskutować godzinę. "Story ma kryteria akceptacji w formacie Given/When/Then" - to jest punkt, bo albo są, albo ich nie ma.
DoR pisze zespół. Twoja rola to facylitacja: przynieś 3 ostatnie stories, które wybuchły w sprincie, i zapytaj "co musielibyśmy wiedzieć wcześniej, żeby tego uniknąć?". Odpowiedzi zespołu to Wasz DoR. Punkty narzucone z góry zespół będzie omijał, punkty własne będzie egzekwował.
Zostaw furtkę na wyjątki. Zdarzy się story, która nie spełnia wszystkich punktów, a mimo to warto ją wziąć (np. spike badawczy). Wtedy zespół podejmuje świadomą decyzję i nazywa ryzyko na głos. To co innego niż branie niedopieczonych stories z rozpędu.
Refinement to miejsce, gdzie DoR żyje. Jeśli robicie refinement raz na dwa tygodnie, godzinę przed planowaniem, żaden DoR Was nie uratuje. Stories potrzebują czasu na dojrzenie: pytanie zadane na refinemencie w środę ma szansę dostać odpowiedź przed planowaniem w poniedziałek.
Definition of Done na trzech poziomach: story, sprint, release
Jedna płaska lista DoD zwykle nie wystarcza, bo różne rzeczy "domykają się" w różnych momentach. W praktyce sprawdza się układ trzypoziomowy:
Poziom story
Standard jakości pojedynczej pozycji backlogu: kod przeszedł review, testy jednostkowe zielone, kryteria akceptacji zweryfikowane przez kogoś innego niż autor kodu, zmiana wdrożona na środowisko testowe. To jest ten DoD, o którym mówi się najczęściej.
Poziom sprintu
Rzeczy, które nie mają sensu per story, ale muszą się wydarzyć, zanim przyrost uznacie za gotowy: testy regresyjne krytycznych ścieżek, aktualizacja dokumentacji, którą czytają inni (instrukcja dla wsparcia, changelog), demo przygotowane na review. Bez tego poziomu "done" na story maskuje "undone" na produkcie.
Poziom release
Bramka wypuszczenia na produkcję: testy wydajnościowe tam, gdzie są istotne, zgody compliance/bezpieczeństwa, komunikacja do użytkowników, plan wycofania zmiany, gdyby coś poszło źle. W organizacjach regulowanych (banki, ubezpieczenia) ten poziom bywa najdłuższy - i dobrze, bo lepiej mieć go na checkliście niż w głowie jednej osoby, która akurat jest na urlopie.
Uwaga praktyczna: im niżej w tej piramidzie potrafisz przesunąć dany punkt, tym lepiej. Jeśli "aktualizacja dokumentacji API" da się robić per story zamiast per release, przesuń ją na poziom story. Dług odkładany do release'u rośnie z odsetkami.
Rola analityka: dostawca "ready", strażnik "done"
DoR i DoD to nie są "sprawy Scrum Mastera". Analityk biznesowy siedzi w samym środku obu bramek.
Po stronie DoR jesteś dostawcą. Większość punktów DoR to wprost Twoja praca: doprecyzowane wymaganie, testowalne kryteria akceptacji, zidentyfikowane zależności i interesariusze, rozstrzygnięte pytania otwarte. Kiedy zespół mówi "ta story nie jest ready", zwykle znaczy to "analiza nie jest skończona". Zamiast się bronić, potraktuj to jako gotową listę zadań na najbliższe dni. Dobry DoR zamienia mgliste "przygotuj backlog" w konkretną kolejkę roboczą.
Po stronie DoD jesteś strażnikiem wartości. Deweloper sprawdzi, czy kod działa. Tester sprawdzi, czy spełnia kryteria. Ale pytanie "czy to rozwiązuje problem biznesowy, od którego zaczęliśmy?" należy do Ciebie. Znam przypadki, w których wszystkie kryteria akceptacji były spełnione, a funkcja i tak nie nadawała się do użytku, bo kryteria opisywały mechanikę zamiast intencji. Analityk na review, który pyta "pokażcie mi to na scenariuszu księgowej zamykającej miesiąc", łapie takie rzeczy jako ostatnia linia obrony.
To zresztą dobra wiadomość, jeśli dopiero celujesz w rolę BA, na przykład przebranżowując się z testowania czy administracji: pracę z DoR i kryteriami akceptacji widać na rozmowie rekrutacyjnej szybciej niż znajomość jakiegokolwiek narzędzia. A że wymagania i praca z backlogiem regularnie pojawiają się w ogłoszeniach dla analityków, możesz sprawdzić samodzielnie w barometrze rynku pracy BA.
Gotowe checklisty DoR i DoD do adaptacji w Twoim projekcie
Potraktuj je jako punkt startowy na warsztat z zespołem, nie jako gotowca do wklejenia w Confluence. Skreślcie, co u Was nie gra, dopiszcie, co Was ostatnio zabolało.
Definition of Ready (story)
- [ ] Story ma opis problemu/celu biznesowego, nie tylko rozwiązania ("po co", nie tylko "co")
- [ ] Kryteria akceptacji są spisane i testowalne (Given/When/Then albo lista warunków z jednoznacznym tak/nie)
- [ ] Zależności zidentyfikowane: inne zespoły, systemy, dostępy, dane testowe
- [ ] Pytania otwarte rozstrzygnięte albo jawnie oznaczone z nazwiskiem osoby, która odpowie, i terminem
- [ ] Story zmieści się w sprincie (jeśli nie - dzielimy przed planowaniem, nie w trakcie)
- [ ] Zespół widział story na refinemencie i wycenił ją
- [ ] Makiety/reguły biznesowe załączone, jeśli story dotyka UI lub logiki obliczeń
Definition of Done (story)
- [ ] Kod przeszedł review co najmniej jednej osoby
- [ ] Testy jednostkowe napisane i zielone; testy istniejące nie zepsute
- [ ] Kryteria akceptacji zweryfikowane przez kogoś innego niż autor implementacji
- [ ] Zmiana wdrożona na środowisko testowe/staging
- [ ] Brak znanych defektów krytycznych; defekty niższej wagi zarejestrowane świadomie
Definition of Done (sprint)
- [ ] Regresja krytycznych ścieżek wykonana
- [ ] Dokumentacja, którą czyta ktoś poza zespołem, zaktualizowana
- [ ] Przyrost pokazany interesariuszom na review
Definition of Done (release)
- [ ] Zgody wymagane w organizacji (bezpieczeństwo, compliance) uzyskane
- [ ] Plan komunikacji do użytkowników i plan rollbacku gotowe
- [ ] Monitoring/alerty dla nowej funkcji skonfigurowane
Jak to wdrożyć bez wojny z zespołem dev
Najczęstszy błąd: analityk albo SM przynosi gotowy dokument i ogłasza "od dziś obowiązuje". Efekt przewidywalny - zespół kiwa głowami i ignoruje. Zamiast tego:
1. Zacznij od bólu. Na retro pokaż dwie ostatnie stories, które wybuchły. Zapytaj, ile kosztowały w przełożeniu na przełączanie kontekstu i przeciągnięte sprinty. Dopiero potem zaproponuj DoR jako eksperyment, nie jako nowy regulamin.
2. Wdrażaj jako eksperyment na 2-3 sprinty. "Sprawdzamy przez trzy sprinty, na retro decydujemy, co zostaje". To zdejmuje opór, bo nikt nie podpisuje się pod czymś na zawsze.
3. Zacznij od 4 punktów zamiast 7. Te, które bolały ostatnio. Lepszy krótki DoR używany w 100% przypadków niż wyczerpujący używany w żadnym.
4. Egzekwuj symetrycznie. Jeśli zespół ma prawo odmówić wzięcia story bez kryteriów akceptacji, to Ty masz obowiązek dowozić kryteria przed refinementem. DoR, który dyscyplinuje tylko jedną stronę, umrze w miesiąc.
5. Przeglądajcie co kwartał. Punkty, których nikt nie złamał od pół roku, można wyrzucić - weszły w krew. Punkty, które łamiecie co sprint, wymagają rozmowy: albo są nierealne, albo problem leży gdzie indziej.
Dobrze napisane DoR i DoD to jeden z tych artefaktów, które odróżniają analityka "spisującego wymagania" od analityka, który realnie podnosi przepustowość zespołu. Tego drugiego nie nauczysz się z definicji - trzeba to przećwiczyć na konkretnych stories, kryteriach i scenariuszach. Dokładnie tak działa platforma Analify: wyzwania z realiów projektowych, peer review Twoich artefaktów i portfolio, które możesz pokazać rekruterowi. Załóż darmowe konto i przećwicz to na własnych artefaktach, zamiast czytać kolejną definicję.
Najczęstsze pytania
Czy historyjka z góry backlogu jest automatycznie gotowa do sprintu?
Nie - pozycja na backlogu mówi o priorytecie, nie o gotowości: historyjka może być najważniejsza i jednocześnie niegotowa. W naszej lekcji o DoR i DoD zespół MediFlow rozważa na planowaniu historyjkę o przekładaniu wizyty z priorytetem potwierdzonym przez Product Ownera, a mimo to odsyła ją na refinement: brak kryteriów akceptacji i makiety, nieoszacowany rozmiar, niegotowa bramka SMS. Priorytet ustala, co robimy najpierw; Definition of Ready sprawdza, czy da się to bezpiecznie zacząć. Drugą przykładową listę, obok checklisty z tego wpisu, zbiera hasło Definition of Ready.
Czy kryteria akceptacji z samym happy path wystarczą, żeby przejść Definition of Ready?
Sam happy path nie wystarczy - przykładowy DoR z naszego minikursu o historyjkach wymaga też co najmniej jednej ścieżki błędu. To ona najczęściej ląduje w koszu; wątek na naszym forum mówi wprost: happy path piszą wszyscy, robotę analityka widać dopiero w tym, co się dzieje, gdy coś pójdzie nie tak. Lekcja o refinemencie pokazuje skutek: historyjka o rezerwacji terminu ma tylko udaną rezerwację, więc pytanie testera o kolizję z inną wizytą rozbija estymację. Jak zapisać ścieżkę błędu w Given/When/Then, pokazujemy w tekście o kryteriach akceptacji.
Jak poznać, że Definition of Ready zaczął hamować zespół zamiast pomagać?
Po dwóch sygnałach z naszego materiału o artefaktach Scruma. Pierwszy: DoR jako broń - odmowa wzięcia historyjki przez jeden brakujący podpunkt, choć lista ma rozmowie pomagać, nie ją zastępować. Drugi: DoR puchnie o makiety zatwierdzane przez kilka działów, specyfikację API i podpis architekta - to faza analizy z bramką odbioru pod modniejszą nazwą; ostrzeżeniem są historyjki czekające na "ready" dłużej niż dwa sprinty. Zdrowy DoR z tej lekcji to kilka punktów jako agenda refinementu, minikurs o historyjkach mówi krócej: bramka, nie mur; sam rytm opisuje hasło backlog refinement.
Co analityk wnosi do Definition of Done poza punktami technicznymi?
Punkty o wymaganiach, których deweloper i tester sami nie dopiszą. Fragment DoD zespołu MediFlow z naszej lekcji o artefaktach Scruma: kryteria akceptacji zweryfikowane na środowisku testowym (najczęściej przez analityka), słownik pojęć uzupełniony, jeśli historyjka wprowadza nowy termin domenowy, reguły biznesowe zapisane w bazie wiedzy zespołu, komunikaty błędów po polsku zaakceptowane przez Product Ownera - ten wszedł, gdy pacjentka zobaczyła surowy angielski komunikat serwera przy odwoływaniu wizyty. Ogólną przykładową listę zbiera hasło Definition of Done.