Mój przepis na dobry Product Backlog Refinement

Scrum nazywa go Product Backlog Refinementem, ktoś inny powie o nim „planning”, „grooming”, albo po prostu „spotkanie zespołu”. Niezależnie od nomenklatury, z reguły nikt za nim nie przepada. Spotkanie projektowe poświęcone zakresowi prac jest zazwyczaj długie, bezproduktywne i nużące (choć czasem burzliwe) – zarówno dla prowadzącego, jak i uczestników. Dziś parę słów o tym, jak to zmienić.

Czym jest Product Backlog Refinement?

Według Scrum Guide, Product Backlog Refinement to ciągły proces, którego celem jest doskonalenie i skonkretyzowanie zakresu produktu (w taki sposób, aby zespół developerski był w stanie efektywnie nad nim pracować).

Doskonalenie (ang. refinement) Product Backlogu to działanie polegające na dzieleniu elementów Product Backlogu na mniejsze, bardziej precyzyjnie zdefiniowane jednostki oraz na ich dookreślaniu. To ciągły proces, którego celem jest dodawanie szczegółów, takich jak opis, kolejność czy rozmiar. Właściwości te często są różne w zależności od specyfiki pracy.

Przewodnik po Scrumie (Scrum Guide)

Nazywanie refinementem spotkania projektowego z zespołem, poświęconego zakresowi produktu, jest więc pewnym nadużyciem. Robię to jednak świadomie – według mojego doświadczenia refinement product backlogu w dużej mierze odbywa się właśnie podczas spotkań projektowych (elementu procesu). I to właśnie im poświęcam dzisiejszy artykuł.

Dobry Refinement, czyli jaki?

To, jakich kryteriów użyjemy do oceny jakości refinementu z pewnością zależy od specyfiki naszego projektu, jego celów, procesu, indywidualnych preferencji, a także szeregu innych czynników. Moje (wierzę, że dość uniwersalne) najważniejsze funkcje, a zarazem cele refinementu to:

• budowanie w zespole świadomości zakresu projektu i roadmapy produktu,
• jednakowe rozumienie zakresu przez cały zespół,
• uzyskanie informacji zwrotnej przez Product Ownera / interesariuszy (opinii zespołu o zakresie projektu),
• ustalenie wspólnej (technicznej, biznesowej, organizacyjnej) strategii realizacji zadań w backlogu,
• wyrównywanie kompetencji w zespole i budowanie w nim poczucia odpowiedzialności za zakres projektu,
• oszacowanie rozmiaru prac / zadań, celem skutecznego planowania.

I to w takiej kolejności. Ktoś mógłby powiedzieć, że dość mało w tym wszystkim orientacji wokół samego zakresu produktu. Być może – ale ja tak właśnie postrzegam refinement. Jako pretekst do tego, aby zespół usiadł razem, nauczył się współpracować, zrozumiał zlecony mu zakres projektu i dogadał się co i jak zamierza zrobić – wspólnie, jako team – aby go w przyszłości zaplanować i zrealizować.

15 sposobów na usprawnienie refinementu

Poniżej prezentuję garść dobrych praktyk i pomysłów na prowadzenie i usprawnienie refinementu. Ich źródłem są moje własne doświadczenia – w różnych firmach, projektach, zespołach i konfiguracjach. Zdecydowanie nie namawiam do wdrażania ich wszystkich (zwłaszcza na raz!) – a raczej eksperymentowania i szukania idealnego zestawu dla własnych potrzeb.

Przed spotkaniem

1. Publikowanie agendy spotkania / planu refinementu z min. jednodniowym wyprzedzeniem. Zespół zobligowany jest do zapoznania się z zaplanowanymi zagadnieniami, wstępnie (indywidualnie) weryfikując ich kompletność, notując wątpliwości i sugestie. Pozwala to zaoszczędzić cenny czas na refinemencie i skupić się na najważniejszych tematach. Agendę publikuje osoba odpowiedzialna za kształt zagadnień w Product Backlogu – np. analityk / Proxy Product Owner.
2. Minirefinementy przygotowawcze, odbywające się regularnie (np. raz w tygodniu), w okrojonym składzie (np. analityk + 2 członków zespołu, wybieranych rotacyjnie). Ich celem jest wstępna weryfikacja zagadnień w Product Backlogu i ich techniczne przygotowanie do refinementu (np. edycja opisów, kryteriów akceptacji, konwersja User Story na Spike itp.) – tak, aby zaoszczędzić czas całego zespołu na właściwym refinemencie.
3. Definition of Ready (DoR, kryterium gotowości) to zbiór zasad przyjętych przez zespół, które decydują o tym, kiedy dane zagadnienie Product Backlogu jest gotowe na rozpoczęcie prac. Ma on na celu ograniczenie problemów podczas developmentu, wynikających np. z niewystarczającego opisu, niewykonania zagadnień zależnych (de facto blokujących realizowane zadanie), braku odpowiednich projektów (np. interfejsu graficznego). Oczywiście brak spełnienia wszystkich punktów nie zabrania omawiania danego zagadnienia na refinemencie (wszak to właśnie tam niektóre kryteria DoR powinny się zmaterializować), daje jednak zespołowi wskazówkę czy zadanie jest gotowe na szerszą dyskusję.

Definition of Ready ( = zagadnienie zostało opracowane i jest gotowe na rozpoczęcie prac developerskich)
1. Opis zadania nie wymaga tłumaczenia, a kontekst biznesowy oraz cel zadania są w nim zawarte,
2. Zadanie zawiera kryteria akceptacji,
3. Zadanie zawiera elementy niezbędne do jego wykonania, m.in. projekt graficzny, klucze tłumaczeń, dostępy itd.,
4. Zależności z innymi zadaniami są rozpoznane i odnotowane,
5. Zadanie zostało omówione i zrozumiane przez cały zespół,
6. Zespół oszacował rozmiar prac,
7. Zadanie nadano właściwe atrybuty w systemie projektowym (komponent, wersja, epic),
8. Zadanie oznaczono statusem „Ready for development”.

Przykład Definition of Ready w jednym z moich projektów

W trakcie spotkania

1. Refinement nie może być zbyt długi. Według danych MeetingKing.com, w przypadku 15-minutowego spotkania możemy liczyć na skupienie 91% uczestników. W 45. minucie spotkania wartość ta spada do 64%. Później jest tylko gorzej. Z tego względu unikam refinementów dłuższych niż 1h (choć byłem kiedyś uczestnikiem projektu, w którym refinementy trwały cały dzień!), zwykle stosując dwa stałe, 60-minutowe refinementy w tygodniu + spotkania dodatkowe, organizowane w miarę potrzeb.
2. Spotkanie prowadzą dwie osoby. Jedna odpowiedzialna za zakres (elementy Product Backlogu do omówienia) np. Product Owner bądź analityk. Druga – np. Scrum Master – odpowiedzialna za efektywność spotkania, jego moderację, aktywizację uczestników, wsparcie organizacyjne, implementację i pilnowanie przyjętych zasad. Nie polecam łączenia obu tych ról podczas refinementu. Nawet jeśli technicznie jest to wykonalne, to bardzo wyczerpująca praktyka dla prowadzącego. Może ona również negatywnie wpłynąć na jego relacje z zespołem (stanie się on bowiem trochę jakby „szefem”).
3. Aby wspomóc Product Ownera bądź analityka w zaznajamianiu zespołu z założeniami poszczególnych zadań, warto zaangażować do tego celu rotacyjnie wybieranego pomocnika. Jest on zobligowany do solidnego przygotowania się do prezentacji tematów znajdujących się w agendzie spotkania i współprowadzenia spotkania. Znacząco odciąża to osoby odpowiedzialne za Product Backlog, zwiększa atrakcyjność refinementu oraz poczucie odpowiadzialności za zakres wśród członków zespołu developerskiego.
4. Z definicji w spotkaniu uczestniczy cały zespół, jednak w zależności od jego agendy i przebiegu, zdarza się, że niektóre specjalizacje zwalniane są (przez Scrum Mastera) z konieczności obecności w wybranych fragmentach (np. projektanci UX podczas rozmów o infrastrukturze IT bądź bezpieczeństwie BackEndu). Pozwala to zoptymalizować koszty refinementu i utrzymać skupienie.
5. Rozmowę o każdym elemencie Product Backlogu rozpoczynamy od umiejscowienia go na roadmapie produktu. Tak, aby zespół miał świadomość istotności tematu, funkcjonalności której jest on częścią oraz ewentualnego horyzontu czasowego. Wprowadzeniem tym zajmuje się Product Owner bądź analityk.
6. 15 minut na jeden temat – trzymamy się w zespole zasady, że nie poświęcamy jednemu zagadnieniu więcej czasu niż kwadrans. Ogranicza to rozwlekłe dyskusje, znużenie i sprowadza temat do meritum. Scrum Master monitoruje upływający czas i odpowiednio moderuje dyskusję. Jeśli w 15 minut nie udaje się omówić zagadnienia do końca, oznacza to że wymaga ono przygotowania do kolejnego refinementu (ustalamy wówczas co należy zrobić/wyjaśnić przed następnym spotkaniem).
   1. Uwaga: moim zdaniem to bardzo dobrze (jest to wręcz konieczne!), aby złożone zagadnienie przebrnęło w ten sposób przez kilka refinementów. Tylko wtedy możemy mieć pewność, że zostało właściwie przemyślane i zrozumiane przez cały zespół, tj. że jest wymaganiem dojrzałym.
7. Stosowanie abstrakcyjnych miar do wyceny zadań, takich jak Story Points bądź T-shirt sizes (rozmiary koszulek) znacząco ułatwia i przyspiesza proces estymacji. Zespół nie traci czasu na zastanawianie są nad dokładną wartością (np. 7h) – która zapewne i tak nie jest adekwatna – a raczej dąży do relatywnego określenia wielkości zagadnienia. Czuje się w tym znacznie swobodniej. Z mojego doświadczenia, abstrakcyjne miary są paradoksalnie bardziej dokładne niż te absolutne.
8. Do wyceny zadań świetnie nadaje się metoda głosowania (Planning Poker) – gdy każdy członek zespołu, po uprzedniej dyskusji, niezależnie od siebie deklaruje własne oszacowanie zagadnienia. Polecam tutaj dwa narzędzia:
   1. Karty do Planning Pokera – przypominające karty do gry, idealne do spotkań on-site (na miejscu), gdy cały zespół jest razem,
   2. PlanItPoker – świetne, darmowe narzędzie do głosowania online (na bazie kart do gry), idealne podczas spotkań wirtualnym, w zespole rozproszonym.
9. Podczas wyceny zadań dążymy do osiągnięcia konsensusu. Nie wyciągamy średniej z podanych przez zespół wartości, a dyskutujemy o nich, próbując zrozumieć się nawzajem i obrać wspólny front, czasem kilkakrotnie powtarzając głosowanie. Jak już wcześniej wspomniałem – dla mnie refinement jest pod wieloma względami pretekstem do zespołowej rozmowy o zakresie. Wycena nie jest tutaj celem samym w sobie.
10. Zgadnienia typu „User Stories” są obecnie powszechnie stosowane w niemal wszystkich agile i quasi-agile’owych projektach. Właściwie skonstruowane i kompletne (patrz punkt o Definition of Ready) są bardzo lekkim i skutecznym nośnikiem wymagań dla zespołu.
11. Zagadnienia typu „Spike” (research) to dobry pomysł w sytuacji, gdy temat jest mętny, wymaga zgłębienia, a końcowy rezultat nie do końca zdefiniowany. Zamiast wróżyć z fusów i tracić czas zespołu na próbę opracowania „w ciemno”, warto przeprowadzić research – z określonym i możliwym do osiągnięcia celem. Właściwe zadanie wykonamy po zapoznaniu się z wynikami „Spike’a”,
12. Na koniec – dość oczywiste, co nie znaczy, że mniej ważne: włączone kamery podczas zdalnych refinementów mocno poprawiają jakość spotkania. Dyskusja osób nieukrywających się po drugiej stronie ekranu jest znacznie żywsza i angażuje większą część zespołu. Dla spotkań „on site” polecam natomiast politykę zamkniętych laptopów (zdecydowanie poprawia skupienie uczestników).

Jestem ciekaw Twojej recepty na dobry Product Backlog Refinement. Koniecznie podziel się nią w komentarzu!