Jak sprawnie przygotować i przeprowadzić backlog refinement?

Wiele firm technologicznych pracuje dzisiaj w scrumie, co narzuca regularne prowadzenie kilku ceremonii z tym związanych. Jedną z nich jest „backlog refinement”, gdzie artefakty planowane na kolejne sprinty są szczegółowo omawiane i doskonalone przez zespół, tak by organizacja kolejnego sprintu przebiegała bez przeszkód, a dostarczony przyrost produktu przyniósł oczekiwaną wartość dla naszego klienta.

W tym artykule chciałabym się podzielić swoimi doświadczeniami oraz kilkoma radami, jak usprawnić proces przygotowania i przeprowadzenia refinementu, który jest kluczowy w sytuacji, gdy zarządzamy pracą nie tylko jednego zespołu scrumowego, ale kilku, a część ich pracy jest wzajemnie powiązania.

Nikt z nas nie lubi długich, nudnych spotkań, gdzie obecnych jest wiele osób, a w dyskusji bierze udział zaledwie garstka uczestników. Takim spotkaniem może stać się backlog refinement, jeśli w porę nie zdamy sobie sprawy, że pora na fundamentalne zmiany w podejściu do jego organizacji i prowadzenia. Odpowiedzialność w tym zakresie spoczywa nie tylko na osobie, która prowadzi takie spotkanie, ale również na jego uczestnikach. Warto pamiętać, że wspólna praca wszystkich członków zespołu w czasie spotkania backlog refinement pozwala na efektywne planowanie i dostarczanie artefaktów w kolejnych sprintach.

PRZED SPOTKANIEM BACKLOG REFINEMENT

Przygotowując spotkanie backlog refinement warto zwrócić uwagę na kilka drobnych rzeczy, które istotnie wpłyną na jakość prowadzenia tego spotkania.

Wielkość i struktura zespołu

Zacznijmy od wielkości i struktury zespołu. Posiadanie w pełni funkcjonalnego zespołu jest istotnym jego atutem. Jeśli jednak liczy on zbyt wielu członków, planowanie staje się prawdziwym wyzwaniem w takim zespołowym „konglomeracie”. Spotkania backlog refinement mają ograniczoną pojemność czasową, a ich wydłużanie w nieskończoność kompletnie mija się z celem. Z biegiem czasu nasze skupienie oraz produktywność zdecydowanie spadają.

Dołączając do zespołu jako Product Manager stajemy się jego integralną częścią. Jest to duży atut, ponieważ szybciej możemy taką sytuację zidentyfikować. Swoimi spostrzeżeniami i pomysłami co do podziału zespołu na kilka mniejszych, bardziej funkcjonalnych warto podzielić się z bezpośrednim managerem zespołu developerskiego lub umieścić ten temat w agendzie spotkania retro.

Mniejsze zespoły pozwalają na moderowanie bardziej efektywnej dyskusji w czasie refinementu oraz umożliwiają aktywne uczestnictwo wszystkich jego członków. Zanim jednak nastąpi fizyczny podział na mniejsze zespoły warto także wcześniej uzgodnić funkcjonalne obszary produktu, za które dany zespół będzie odpowiedzialny.

Najważniejsze informacje w zaproszeniu na spotkanie

Drugim ważnym aspektem, na który trzeba zwrócić uwagę jest przygotowanie do spotkania. Nic tak nie spowalnia refinementu jak przypadkowo dobrane rzeczy do dyskusji oraz fakt, że uczestnicy nie mają możliwości na wcześniejsze zapoznanie się z historyjkami. Przejrzenie listy z przygotowanymi historyjkami pozwala na sformułowanie dodatkowych pytań oraz propozycji implementacji. Dlatego w treści zaproszenia na to spotkanie w outlooku zawsze umieszczam historyjki, które będziemy omawiać oraz dodatkowo grupuję je w obszary funkcjonalne, tak by dostarczyć szerszy kontekst poszczególnych elementów.

Praca własna – odpowiednie przygotowanie historyjek do refinementu

Nie można także zapominać o pracy własnej Product Managera lub Product Ownera. W swojej pracy staram się możliwie jak najlepiej przygotować historyjki z punktu widzenia użytkownika. Dobrą praktyką, którą stosuję, jest przygotowanie na poziomie epika lub feature opisu, jakie kroki użytkownik powinien być w stanie wykonać dzięki funkcjonalności. Dzięki temu już na tym etapie staje się wtedy możliwe sformułowanie dodatkowych pytań oraz zidentyfikowanie obszarów, które ja jako Product Manager muszę zaadresować z innymi zespołami lub interesariuszami. Patrzenie wprzód pozwoli na uniknięcie „blokerów” już po rozpoczęciu prac nad daną funkcjonalnością. Lubię tutaj stosować technikę User Story Mapping. Jest to dla mnie bardzo dobre ćwiczenie, które pozwala na szybką weryfikację poszczególnych obszarów danej funkcjonalności. Wychodząc jeszcze bardziej frontem do zespołu sama tworzę historyjki, które dokładnie opisują zachowanie użytkownika oraz zawierają Kryteria Akceptacji.

Komunikacja asynchroniczna, regularne konsultacje

Bardzo dużą wagę przywiązuję także do komunikacji asynchronicznej z poszczególnymi członkami zespołu. Jest to szczególnie pomocne, gdy mam wątpliwości co do właściwego przygotowania danej historyjki. Taka szybka konsultacja pozwala mi na wcześniejsze udokumentowanie kwestii, które przy omawianiu muszę poruszyć lub upewnić się, że dana historyjka jest gotowa do omówienia w czasie spotkania refinement. To dla mnie duża pomoc zwłaszcza w sytuacji, gdy mamy do czynienia z historyjkami bardzo technicznymi.

Warto także wcześniej zidentyfikować te obszary, które będą wymagały uczestnictwa w spotkaniu Subject Matter Expert, dedykowanego Product Managera lub innego stakeholdera. Obecność takiej osoby na spotkaniu pozwoli niemal natychmiast zaadresować kwestie typowo biznesowe. Opcjonalnie można rozważyć zorganizowanie osobnego spotkania z taką osobą dla zespołu poza refinementem.

Przygotowanie Planning Pokera i zakładek w przeglądarce

Tuż przed rozpoczęciem spotkania wysyłam link to sesji Planning Poker, aby potem nie tracić czasu na generowanie linku do sesji Planning Poker, wysyłanie jej w czasie spotkania na czacie i czekanie aż wszyscy dołączą. Innym usprawnieniem w tym obszarze jest otwarcie wszystkich zaplanowanych na spotkanie historyjek w osobnych zakładkach przeglądarki. Choć może wydawać się to drobnostką, to naprawdę takie drobne czynności usprawniają całe spotkanie. Dzięki temu mogę szybko się przełączać między poszczególnymi historyjkami oraz wracać do poprzednich, jeśli zaistnieje taka konieczność

W CZASIE SPOTKANIA BACKLOG REFINEMENT

Pora na sprawne poprowadzenie spotkania. Tutaj też mam kilka propozycji, jak uczynić to spotkaniem bardziej interaktywnym i angażującym wszystkich uczestników.

Skupienie uwagi uczestników

Maksymalnie skup uwagę uczestników. Nie jest to łatwe, gdy część z nich prowadzi tzw. multitasking na Slacku, Teams oraz Outlook. Gdy prezentuję daną historyjkę omawiam jej zakres oraz jaką wnosi wartość. Następnie zostawiam pole do zadawania pytań i poddawania w wątpliwość wcześniej ustalonych założeń. Wymusza to na zespole konieczność pełnego skupienia, co jest dużym wyzwaniem, gdy część uczestników dołącza do spotkania online. Ponadto w mniejszym zespole łatwo zidentyfikować, kto aktywnie uczestniczy w dyskusji i zaprosić do zabrania głosu tych, którzy są mniej zaangażowani. Często w mniejszych zespołach jego uczestnicy czują się bardziej odpowiedzialni za daną funkcjonalność i chętnie dostarczają swój feedback. Zauważyłam także, że szczegółowa dyskusja pozwala doprecyzować, jak dana historyjka może zostać przetestowana. To bardzo istotne w sytuacji, gdy nie można stworzyć automatycznych testów lub koszt ich tworzenia przewyższa wartość, jaką wnoszą.

Dzielenie historyjek na mniejsze zadania i dodawanie nowych

W czasie prowadzenia spotkania identyfikujemy również brakujące historyjki. Przy ich omawianiu zespół komunikuje, co konkretnie trzeba wdrożyć od strony backend, frontend lub infrastruktury, aby spiąć daną funkcjonalność od A do Z.

Na tym etapie tworzę tzw. drafty historyjek i deleguję ich szczegółowy opis do konkretnej osoby, która od tego momentu będzie odpowiedzialna za jej uszczegółowienie. Podobnie robię przy historyjkach, które wymagają jedynie uzupełnienia, ale musi się tam znaleźć istotna informacja z punktu widzenia frontend lub backend. Takie historyjki znajdą się ponownie w następnej agendzie spotkania grooming do ponownej weryfikacji lub zakwalifikowane artefakty gotowe do estymowania. Uważam, że takie zaangażowanie użytkowników daje im poczucie, że czują się misjonarzami, a nie najemnikami produktu, o czym pisze Marty Cagan w swojej książce „Zainspirowani”.

Weryfikacja zrozumienia zadania przez zespół

Po omówieniu danej historyjki pora na ich weryfikację, czy wszyscy ją zrozumieli oraz czy spełnia kryteria Definition of Ready. Nie będę się w tym artykule rozpisywać na temat technik oraz podejść do estymowania. Więcej informacji na ten temat możecie znaleźć tutaj. Warto jednak estymować historyjki zaraz po ich umówieniu. Początkowo omawiałam całą grupę historyjek zaplanowanych na spotkanie, a ich estymowanie zostawiałam na sam koniec. To rozwiązanie niestety się nie sprawdziło. Czas spotkania dobiegał końca, a ja pozostawałem z grupą omówionych historyjek, prawie gotowych do pracy, ale nie wyestymowanych. Kończyło się to rozpoczęciem kolejnego spotkania grooming od estymowania historyjek z poprzedniego spotkania i wymagało od uczestników ponownego odtwarzania informacji i zostawiało mniej czasu na omawianie nowych rzeczy.

Profesjonalne trzymanie się ram czasowych

Należy pamiętać także o trzymaniu ram czasowych spotkania. Punktualne pojawianie się na spotkaniu jest wyrazem szacunku do ich uczestników oraz ich czasu. Nie przedłużajmy także spotkania w nieskończoność. O ile 5 minut jest do zaakceptowania w sporadycznych przypadkach, o tyle już wydłużanie spotkania o kolejne 30 minut mija się z celem i powoduje uzasadnioną frustrację. Nawet jeśli nie wszystko uda się omówić, co jest zaplanowane w agendzie to te rzeczy, które udało się doprecyzować jest bardzo dużym zyskiem dla całego zespołu. Jestem mocno przekonana, że warto nawet zrobić dwa krótsze spotkania groomingowe w ciągu tygodnia niż jedno, które będzie na siłę przeciągane. Stąd też dużo lepiej jest pracować w mniejszych zespołach, ponieważ mamy do dyspozycji dużo większa przestrzeń do wzajemnej interakcji uczestników oraz znalezienia dogodnego czasu na spotkanie dla wszystkich.

PO SPOTKANIU BACKLOG REFINEMENT

Pora na podsumowanie spotkania, zebranie wniosków oraz zaadresowanie „action items” dla poszczególnych członków zespołu. Po spotkaniu formułuję krótkiego maila z listą rzeczy, które omawialiśmy. Przy każdym z nich wskazuję osobę z zespołu lub siebie, jako osobę odpowiedzialną za dany artefakt i co konkretnie powinna z nim zrobić. Np. Anna – porozmawiać z PM z danego obszaru i zaadresować pytania (…), Feliks – uzupełnić opis historyjki oraz dodać informację jak ją przetestować nim zostanie zaakceptowana przez QA.

“Action items” korespondują z konkretnymi historyjkami, które omawiamy. Dlatego osoba odpowiedzialna za “action item” jest przypisywana jako owner danej historyjki, przynajmniej do kolejnego spotkania backlog refinement. Dodatkowo np. w komentarzu umieszczam informację, czego konkretnie oczekuję w ramach danego “action item”. Przygotowane informacje przez ownerów danego artefaktu prezentowane są w czasie kolejnego refinementu.

PODSUMOWANIE

Mam nadzieję, że powyżej przedstawione przykłady oraz własne doświadczenia pozwolą choć w części usprawnić Wasze spotkania backlog refinement i dostarczać coraz lepsze funkcjonalności oraz produkty w kolejnych sprintach.