DEEP odpowiada na pytanie, jakie kluczowe cechy powinna posiadać dobra lista wymagań naszego produktu/projektu. I tak, wiemy, że jest to kolejny zwinny akronim do już i tak bogatej kolekcji.
Pomysł na DEEP
Pisaliśmy już o INVEST, SMART, MoSCoW i paru innych mnemonikach mocno związanych ze zwinnym podejściem. Dziś przedstawimy Wam kolejny, tym razem dotyczący jednego z naszych ulubionych artefaktów, czyli Product Backlogu. Jeśli jeszcze nie wiecie czym on jest, koniecznie zajrzycie do bardzo popularnego tekstu, w którym w szczegółach opisujemy czym jest i po co istnieje właśnie ten artefakt.
Znacznie mniej osób zapewne wie, czym jest DEEP. Na ideę mnemonika wpadł Roman Pichler, który tworząc go zwrócił uwagę na cztery istotne z jego punktu widzenia cechy backlogu. Ja się z nimi w pełni zgadzam i mam nadzieję, że Wy już za moment też będziecie.
Piszemy o tym akurat dziś, bo po wczorajszym filmie „Kiedy Product Owner akceptuje prace Zespołu Deweloperskiego?„, naszła mnie myśl związana z potencjalną przyczyną „konieczności” akceptacji prac. Jest to kiepskiej jakości Backlog.
Jak poradzić sobie z tym stanem rzeczy? Sprawdźmy, czy nie pomoże nam w tym właśnie DEEP!
[D]eep, czyli „D”
Z angielskiego deep to… głęboki. Zapewniam, że nie o to chodzi w tym przypadku. DEEP to skrót powstały od pierwszych liter słów, które się na niego składają:
- Detailed enough (for now)
- Estimated
- Emergent
- Prioritised
DEEP jest czymś zupełnie innym niż znane nam atrybuty Elementów Backlogu Produktu. DEEP określa kluczowe cechy całego backlogu, a nie tylko jego poszczególnych elementów. A te to, dla przypomnienia, opis, kolejność, oszacowanie i wartość. Podobne? Nie do końca. Przyjrzyjmy się zatem co oznacza DEEP.
Detailed enough to nic innego jak odpowiednia szczegółowość listy wymagań. „Odpowiednia” jest tak niedookreślonym terminem, że każdy rozumie pod nim coś innego. Czy jest jakiś jeden idealny wzór na szczegółowość?
Niestety, nie ma. Wszystko zależy od organizacji, w której pracujemy i momentu życia, w jakim się znajdujemy. A nawet od scrumowej dorosłości zespołu. Wszystko ma znaczenie w określeniu poziomu szczegółowości. Ta zależeć będzie na pewno od priorytetu danego wymagania. Te znajdujące się na szczycie backlogu opisane będą bardziej szczegółowo niż wymagania, znajdujące się na jego końcu.
Tylko pamiętajmy, że ta cecha jest zmienna w czasie. Skoro zmieniają się warunki, to i zmienia się znaczenie pierwszej litery naszego DEEP.
d[EEP], czyli co jeszcze?
Estimated, czyli oszacowany to nic innego jak „wyceniony przez Zespół Deweloperski„. Zgodnie z wpisem Mike’a Cohn’a:
„The product backlog is more than a list of all work to be done; it is also a useful planning tool.”
Zgadzam się z tym podejściem w stu procentach. Product Backlog jest narzędziem do planowania – czy to zakresu całego produktu, czy najbliższej iteracji. Podobnie jak ze szczegółowością wymagań, elementy znajdujące się na szczycie backlogu oszacowane będą precyzyjniej (mamy o nich większą wiedzę). Z kolei wycena elementów znajdujących się na dalszych pozycjach listy jest bardziej szacunkowa. Nie znamy (do końca) zakresu, nawet nie mamy pewności, że będziemy je realizować. Oszacować musimy, ale czy będziemy go dokonywać z wielką precyzją?
Emergent, czyli wyłaniający się. Product Backlog nie jest nigdy skończony, bo Scrum nigdy się nie kończy. To nie jest statyczna lista elementów, które mają zostać zaimplementowane w naszym systemie. Im więcej wiemy o użytkowniku, im bardziej poznajemy produkt czy domenę, w której przyszło nam działać, tym szybciej wymagań będzie przybywać. Nie ma w tym nic dziwnego, przecież Product Backlog najczęściej budujemy metodą top – down.
Prioritized, czyli spriorytetyzowany. Elementy listy wymagań powinny być spriorytetyzowane, powinny więc posiadać kolejność. Jest ona ustalana przez Product Ownera, właściciela Backlogu Produktu. Nie posiadając priorytetów, zespół nie będzie w stanie zaplanować się z uwzględnieniem maksymalizowania wartości dostarczanego produktu czy swojej „utylizacji” (nie lubię tego słowa, ale użyć go muszę).
Czy Twój backlog jest DEEP?
Zaryzykowałem wyżej stwierdzenie, że DEEP jest nam w stanie pomóc w zadbaniu o dobrej jakości Backlog. Nawet jeśli nie wyeliminuje wszystkich problemów, to pozwoli je znacząco ograniczyć. Aby dojść do pełni szczęścia, powinniśmy zejść na poziom wymagań i zapewnić ich poprawny opis. Tu mogą nam pomóc np. wspomniane kryteria INVEST przy User Story. Warto też ustalić wartość biznesową każdego z elementów. I tak przygotowany Backlog będziemy mogli uznać za wartościowy.
Przejrzyjcie swoje listy wymagań, sprawdźcie proszę, czy są one DEEP. Jeśli nie, to jest ten czas, aby przysiąść i wprowadzić poprawki. Zasady możemy ustalić na Sprint Retrospective, a jakość backlogu poprawić na Product Backlog Refinement. Ale po co czekać? Od tego zależy przecież to, jak będzie nam się pracowało, jak będziemy dostarczać wymagania i czy będziemy wymagali dodatkowych akceptacji przyrostu, czy też nie.
A czy Twój Backlog Produktu jest DEEP?
