Definition of ready - co to jest, kiedy się przydaje, jakie są z nią rpoblemy.

1. DEFINITION OF READY
co daje, kiedy jest potrzebne i jak je zaimplementowad mimo oporów?

2. Definition of ready - co to jest ?
1. Nie występuje w core scrum.
2. Musi byd spełniona zanim zadanie można wziąd na
sprint.
3. Praca nad jej wypełnieniem może byd wykonywana i
przez PO i przez zespół - jest to normalna praca nad
wymaganiami.
4. PO jest odpowiedzialny za dostarczenie
dostatecznej ilości elementów backlogu
spełniających DoR na planning.

3. Definition of ready - przykład
1. Wymaganie musi byd zaprezentowane
zespołowi przed sprint planningiem.
2. Wymaganie musi przedstawiad jasno
precyzowalną wartośd biznesową.
3. Musi byd określone dla niego DoR.

4. Definition of ready - dokładniejszy
przykład
1. Wymaganie musi przedstawiad wartośd dla PO i wartośd ta musi byd przedstawiona
zespołowi w sposób nie budzący wątpliwości.
2. Wymaganie musi byd dostatecznie dobrze wyprecyzowane, by zespół był w stanie
je wyestymowad i dostatecznie małe by był w stanie podjąd się go w jednym
sprincie.
3. 3 członków zespołu musi stwierdzid, że wymaganie spełnia punkt 2 podpisując się
na backlogu produktu.
4. Wykonanie wymagania nie może sprawiad , że nowa wersja produktu nie będzie
mogła zostad uruchomiona w środowisku produkcyjnym.
5. Wszelkie czynności niezależne od zespołu muszą byd wykonane przed początkiem
sprintu.

5. Definition of ready - kiedy przydatne
W zasadzie zawsze - nie zawsze musi byd explicite.
Wymagania zawsze muszą byd w jakiś sposób ustalone
przed tym jak zespół będzie w stanie je wziąd na
warsztat w czasie sprintu. Praca nad tymi wymaganiami
zawsze musi zostad wykonana - co najwyzej może byd
ona dorozumiana i nie wymagad precyzyjnej definicji

6. Definition of ready - kiedy niezbędne
Kilka symptomów potrzeby wprowadzenia twardego definition of
ready:
1. Sprint planning przestaje mieścid się w timeboxie.
2. Na planningu są brane zadania które zależą od "tak
tak, dostaniecie ten content jutro"
3. Zespół nie jest w stanie dostarczyd działającej wersji
produktu pod koniec sprintu mimo iż nie spodziewał się tego
na planningu.
4. Zespół regularnie przedstawia wykonane zadania pod koniec
sprintu i PO uważa, że chciał czegoś innego.

7. Definition of ready - problemy
1. Co będzie jeżeli nie będzie przygotowanego
backlogu ?
2. Kto odpowiada za tworzenie wymagao ?

8. Studium przypadku - podejście 1
Powód :
3 sprinty z rzędu oddane było zadanie, PO je akceptował bo było
zgodne z DoD ustalonym, ale wrzucał nowa wersję zadania na
warsztat.
Próba rozwiązania:
Ustalenie delikatnej DoR (na kształt przykładu 1).
Problem:
Po 1 sprincie nie było już wymagao odpowiednio
podefiniowanych, PO stwierdzil, że nie jest w stanie
zacommitowad się do DoR.

9. Studium przypadku - podejście 2
Powód:
Praca nad wymaganiami prowadzona była chaotycznie, nikt
zajmujący się tematem, nie był w stanie zmusid się do pracy w
większym porządku - wszyscy mówili, że jest to potrzebne.
Próba rozwiazania:
Zaproponowanie DoR - wraz z twarda regułą nie przyjmowania
zadao które DoR nie spełniają.
Problem:
PO powiedział, że nie czuje się na siłach podjąd zobowiązania i ze
woli szukad innego rozwiązania.

10. Studium przypadku - podejście 3
Team memberzy którzy zajmowali się pracą nad wymaganiami
zauważyli, ze nie są w stanie poruszad się sprawnie po rozrastającym
się backlogu i nie zawsze wiedzieli czy na pewno mają pracowad nad
danymi konkretnymi zadaniami. Zaproponowali wprowadzenie
dodatkowego backlogu - na wymagania które w ogóle są jedynie jako
koncepty. Jednocześnie zbiegło się to w czasie z wyjazdem PO na urlop
na 2 sprinty - zastąpiony na ten czas miał byd przez osobę która nigdy
tej roli nie pełniła.
Przez te 2 tygodnie udało się skutecznei prowadzid DoR - po powrocie
właściwy PO był już przekonany do pomysłu i uczciwie zajął się
jedzeniem kanapki, dopilnowywaniem by dostatecznie dużo zadao o
odpowiedniej kompozycji było przygotowanych na czas.

11. Tool page elements
analysis
Dziękuję za uwagę!