Backlog refinement czy grooming czyli jak dbać o Product Backlog?

Bardzo lubię analogię, że Product Backlog jest jak ogród lub sad. Niepielęgnowany i niedoglądany przez ogrodnika zarośnie chwastami, straci swój kształt, nie wyda owoców i kwiatów, albo zostaną one zjedzone przez szkodniki.
Takim swoistym ogrodnikiem w Scrumie jest nie kto inny jak Product Owner. Musi on stale dbać o Backlog swojego Produktu i utrzymywać go w porządku, aby możliwe było skupienie się na dostarczaniu wartości i podejmowaniu szybkich decyzji, a nie na frustrujących i czasochłonnych, jirowych wykopaliskach. Pomoże nam w tym Backlog refinement.

Grooming czy refinement?

Zanim jednak przejdę do kilku krótkich porad jak dbać o swój Backlog, słówko wyjaśnienia czym różni się Backlog grooming od Backlog refinementu. Otóż teoretycznie niczym :). Oba te słówka oznaczają proces pielęgnowania Backlogu Produktu, czyli uzupełniania jego elementów, dodawania szczegółów, dzielenia i estymowania zadań na mniejsze czy po prostu decydowaniu o kolejności realizacji. Do niedawna proces ten nosił nazwę „grooming”. Obecnie używa się słówka refinement. Powodem zmiany było to, że w języku angielskim to pierwsze określenie, pomimo pozytywnego skojarzenia z salonami groomerskimi, ma również drugie, negatywne znaczenie związane z nawiązywaniem bliższych relacji z nieletnimi. A zatem aby uniknąć nieprzyjemnych nieporozumień zamieniono je na refinement i tego się trzymajmy.

Jak pielęgnować Backlog?

Skoro kwestię nazewnictwa mamy za sobą, to przejdźmy do kilku praktycznych porad czyli tak zwanego mięska. Poniżej kilka wskazówek podpartych moim osobistym doświadczeniem.

Rozmawiaj z Deweloperami

Oczekiwania biznesowe względem Zespołu Scrumowego to jedno, a techniczne ograniczenia czy problemy związane z realizacją zadań to drugie. Aby uniknąć nieporozumień i marnotrawienia czasu, warto już na wczesnym etapie przygotowywania elementów Product Backlogu angażować w ten proces Deweloperów. Nie tylko pozwoli to na wczesne zidentyfikowanie potencjalnych wyzwań, ale także poprawi biznesowe rozumienie rozwijanego Produktu w zespole.

Bardzo częstym błędem, który obserwuję wśród Product Ownerów jest zbyt długie i przesadnie szczegółowe przygotowywanie wsadu do Backlogu. Zanim opracowywane przez nich historyjki zostaną pokazane deweloperom, mijają dni czy wręcz tygodnie. PO podejmują próby opisania absolutnie wszystkiego co tylko przyjdzie im do głowy jak gdyby jutra miało nie być. Nie tędy droga! Im szybciej zderzymy nasze (użytkowników) potrzeby biznesowe z zespołem tym szybciej będziemy w stanie podjąć decyzje odnośnie ich kolejności w Backlogu.

Co za dużo to niezdrowo

Nie przesadź też w drugą stronę. Nadmiar refinementu jest równie szkodliwy jak jego brak. Nie żyjemy w próżni, a w szybko zmieniającym się, złożonym świecie, gdzie próba przewidzenia zbyt odległej przyszłości jest z góry skazana na porażkę. Jeżeli na górze swojego Backlogu masz już na tyle historyjek i zadań, że twój zespół jest w stanie zaplanować z grubsza dwa Sprinty wprzód to może warto na chwilę przystopować. Co z tego, że dane zadanie jest już w pełni zrozumiałem przez zespół, opisane i wyestymowane skoro patrząc na kolejkę, wrócisz do niego za dwa, trzy miesiące? Pomijając ulotność ludzkiej pamięci, to wiele może się po prostu do tego czasu zmienić, a więc nie ma sensu traktować procesu refinementu niczym jednorazowej fazy zbierania wymagań w wielomiesięcznym projekcie waterfallowym. Będzie to po prostu marnotrastwo w postaci tak zwanej nadprodukcji czyli lean’owe muda.

Nie bój się zmian decyzji

Istotą podejścia agile’owego jest szybkość adaptowania się do zmian. Jak to podobno powiedział Darwin:

Gatunkiem, który przetrwa, nie jest ten najsilniejszy, ani najinteligentniejszy. Przetrwa ten, który potrafi się zmieniać.

Karol Darwin

A zatem jeżeli w toku prac nad Produktem okazuje się, że jednak potrzebne jest coś innego, musimy zmienić kolejność w Backlogu, dorzucić coś nowego, przepisać istniejącą już funkcjonalność, podjąć inną decyzję to… nie lękajcie się ;)! Im szybciej, tym lepiej i z korzyścią dla końcowego odbiorcy naszej pracy.

Nadmierna formalizacja refinementu

Bardzo często obserwuję, że refinement występuje w różnych zespołach jako sformalizowane, dodatkowe, cykliczne spotkanie, które odbywa się bez względu na aktualny stan naszego Backlogu. Efekt tego jest taki, że często po prostu marnujemy czas, no bo „skoro było w kalendarzu i już się spotkaliśmy no to pogadajmy…”
Jeżeli dla zabicia czasu spotkania w twoim zespole padają pomysły, że może w takim razie pogadamy o czymś co będzie realizowane za pół roku to cytując klasyka „wiedz, że coś się dzieje”. Podobnie jeżeli w danym momencie nikt nie jest przygotowany do dyskusji o konkretnych historyjkach, bo dopisał ją 2 minuty temu i zaczyna się od „Jako Product Owner, chce aby…”. Jeszcze innym antywzorcem, który spotykam w organizacjach jest wykorzystywanie tego spotkania w pierwszej kolejności, żeby uporządkować to co się dzieje aktualnie w Sprincie, bo zespół się już pogubił ;).

Potrzeba dyskusji i uszczegóławiania kolejnych elementów z Backlogu powinna wychodzić naturalnie, wraz z decyzjami o priorytetach. Proces refinementu powinien być… no właśnie, procesem i to do tego ciągłym. Nie sprowadzaj go do cyklicznego spotkania, które spontanicznie zapychamy jakąś dyskusją, no bo przecież Backlog trzeba pielęgnować. Przypomnij sobie analogię z ogrodem. Drzewka owocowe przycinamy i pryskamy regularnie, ale wtedy kiedy trzeba i ma to sens, a nie w co drugi czwartek miesiąca.

Wypracuj własne sposoby na Backlog refinement

Nie szukaj gotowca i złotej listy, którą wystarczy bezmyślnie skopiować, bo taka po prostu nie istnieje! Istotą podejścia agile’owego jest przecież doświadczanie, empiryzm i eksperymentowanie. Nie bój się próbować własnych, pasujących do twojego zespołu i kontekstu, pomysłów, obserwuj jaki mają wpływ na porządek w twoim Backlogu i jakie przynoszą „owoce”. Powyższe rady są zatem inspiracją i zachętą do próbowania na własnej skórze.

A Wy jakie macie doświadczenie z backlog refinementem? Podzielcie się komentarzem poniżej.