Doskonalenie Backlogu Produktu, czyli jak „Przygotować”, aby nie “Przegotować”

1
Czas Czytania: 5 min

Kromka ciepłego, świeżo upieczonego pszennego chleba, z kruchą i pachnąca skórką oraz rozpływającym się masłem to jedno ze wspomnień, dzięki którym wracam do czasów dzieciństwa. Ten popularny wypiek, składa się z niewielkiej ilości składników. Niezwykle istotne jest zatem, aby do jego produkcji użyć ich w jak najlepszej jakości w celu osiągnięcia niezapomnianego smaku. Włosi zwykli nawet mawiać: „kto ma dobrą mąkę, ten zrobi dobry chleb”. Przenosząc to porównanie na kontekst Scruma, rzekłbym, że kto ma dobre doskonalenie Backlogu Produktu, ten jest w stanie robić dobry produkt. I to właśnie doskonalenie (ang. refinement) Backlogu Produktu jest bohaterem dzisiejszego wpisu. Dzięki jego pomocy można bowiem zwiększyć skuteczność Planowania Sprintu, a także wartość rozwijanego produktu.

Co zatem dzisiaj w menu? Na przystawkę parę słów o celu oraz wartości jaką dostarcza doskonalenie Backlogu Produktu, natomiast na danie główne zaserwuję inspirację, która bazując na podejściu Merge-Diverge-Merge pokaże jak w praktyce podejść do procesu refinementu.

Jaki jest cel refinementu?

Doskonalenie Backlogu Produktu zostało opisane w Scrum Guide jako ciągły proces (nie wydarzenie), który polega na uszczegóławianiu i porządkowaniu elementów Backlogu Produktu przed rozpoczęciem pracy nad nimi w kolejnych Sprintach. Celem jest osiągniecie stanu, w którym Zespół Scrumowy będzie mógł określić je, jako „Przygotowane”. Ponieważ stwierdzenie „przygotowany” jest opinią, to każdy może interpretować je na inny sposób. Tu z pomocą Zespołowi Scrumowemu przychodzą ramy tego pojęcia, które dotykając każdego elementu Backlogu Produktu, wyglądają następująco:

  1. wystarczająco zrozumiały, aby Zespół Deweloperski rozumiał potrzeby interesariuszy,
  2.  wystarczająco mały, aby można było go zrealizować podczas pojedynczego Sprintu,
  3. przejrzysty, aby jednoznacznie można było określić jego kolejność w Backlogu Produktu oraz stan przygotowania.
Jak osiągać tak określony cel?

Poprzez zaangażowanie całego Zespołu Scrumowego, traktowanie refinementu, jako czynność wykonywaną w każdym ze Sprintów oraz stała inspekcję i adaptację wypracowywanego podejścia. W efekcie powinniśmy otrzymać elementy Backlogu Produktu, zawierające takie atrybuty jak: wartość, opis, kolejność oraz oszacowanie. Warto też wspomnieć, że w procesie doskonalenia rozważamy nie tylko elementy, których wcześniej nie widzieliśmy na oczy, ale również takie, które „wróciły” do Product Backlogu z poprzednich Sprintów. To, co podlega doskonaleniu nakierowane powinno być bowiem na bieżące dostarczanie wartości w produkcie, który wytwarzamy, a ta może zmieniać się wraz z czasem oraz feedbackiem.

W praktyce wygląda to tak, że Zespół Scrumowy, w duchu podejścia „Just-in-Time, przygotowuje elementy Backlogu Produktu patrząc na horyzont najbliższego jednego bądź dwóch Sprintów. Istotne jest tutaj, aby nie „Przegotować” żadnego z elementów. Celem jest dostarczenie odpowiedniej ilości informacji, aby Zespół Deweloperski mógł zacząć pracę nad danym elementem produktu, a nie wytworzenie obszernej dokumentacji.  Dodatkowo, kierując się zasadą „Individuals and interactions over processes and tools” zostawiamy możliwość współpracy zespołu z interesariuszami, w celu bieżącego doprecyzowywania oczekiwań.

Merge-Diverge-Merge

Jednym z przykładów jak praktycznie podejść do tematu refinementu jest podejście, które w prostych słowach można określić jako „Razem-Osobno-Razem”. W rozbiciu na poszczególne kroki, wygląda ono następująco:

1. Merge (Razem)

Właściciel Produktu przedstawia Zespołowi Scrumowemu cel oraz potencjalną listę elementów Backlogu Produktu na najbliższy jeden/dwa Sprinty. Elementy te mogą być w stanie „surowym”, natomiast istotne jest, aby Właściciel Produktu był w stanie odpowiedzieć, jaką wartość ich dostarczenie wniesie do produktu. Jeżeli zaistnieje taka potrzeba, najważniejsze szczegóły mogą być doprecyzowane przez zaproszonych na to spotkanie interesariuszy.

Po krótkim omówieniu wizji, Zespół Deweloperski decyduje, kto i w ile osób będzie odpowiedzialny za ustalenie większej ilości konkretów odnośnie omówionych elementów Backlogu Produktu.

2. Diverge (Osobno)

Poszczególni członkowie Zespołu Deweloperskiego, pracując w grupach bądź pojedynczo, „przygotowują” poszczególne element Backlogu Produktu. Sprawdzają możliwości techniczne, zależności, przypadki brzegowe, aby zebrać wystarczającą ilość informacji do rozpoczęcia pracy. W razie potrzeby konsultują się z Właścicielem Produktu czy interesariuszami.

3. Merge (Razem)

W momencie, gdy dana grupa uzna, że posiada już wystarczającą ilość danych potrzebnych do rozpoczęcia pracy nad konkretnym elementem, zwołuje resztę zespołu Deweloperskiego i przedstawia otrzymane rezultaty. Następnie cały Zespół Deweloperski oszacowuje omówiony element Backlogu Produktu i upewnia się, że może traktować go jak „Przygotowany”.

4. Podsumowanie

Pod koniec Sprintu Zespół Scrumowy powinien posiadać i rozumieć listę „Przygotowanych” elementów Backlog Produktu, które są jednocześnie kandydatami na najbliższe Planowanie Sprintu.

Wykorzystując przedstawione kroki na gruncie kulinarnym oraz posługując się symbolem mąki z początku wpisu (tym razem jako składnik bułki), przygotowanie burgera w podejściu Merge-Diverge-Merge wyglądałoby następująco:

Lokalnie czy zdalnie?

Podejście Merge-Diverge-Merge można przeprowadzić zarówno w formie warsztatów w jednej lokalizacji, jak również w formie zdalnej. Dobrą praktyką jest zadbanie o dywersyfikacje doskonalonych elementów Backlogu Produktu. Sprowadza się to do angażowania różnych osób z Zespołu Deweloperskiego w weryfikację danych obszarów produktu, a także zmienianie ich podczas dewelopmentu w nadchodzących Sprintach.

Z powodzeniem ideę Razem-Osobno-Razem, można wykorzystać również w każdym innym spotkaniu, którego celem jest wypracowanie wspólnego rozwiązania. Stosując ją do doskonalenia Backlogu Produktu, zachęcam do poszukiwania własnych implementacji oraz eksperymentów, dzięki którym Zespół Scrumowy „Przygotuje” a nie “Przegotuje” elementy Backlogu Produktu.

Bon Appetit!