Czym jest Refinement Backlogu Produktu?

Refinement, znany także jako pielęgnacja Backlogu Produktu, to proces, w którym zespół Scrumowy wspólnie pracuje nad lepszym zrozumieniem i przygotowaniem elementów znajdujących się w Product Backlogu. Choć Scrum Guide nie definiuje Refinementu jako formalnego wydarzenia, proces ten odgrywa ważną rolę w zapewnieniu, że Backlog Produktu pozostaje aktualny, a jego elementy są odpowiednio przygotowane do realizacji w nadchodzących Sprintach. Wcześniej była też używana nazwa grooming, ale została wycofana z powodu złych skojarzeń.

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. — Scrum Guide 2020

Product Backlog może ciągle się zmieniać. Refinement pozwala zespołowi lepiej zrozumieć zakres, oszacować wielkość elementów i podzielić je na możliwe do ukończenia w jednym Sprincie. Dzięki temu zespół może unikać niejasności w trakcie Sprintu i skupić się na efektywnej realizacji zaplanowanej pracy. Im lepszy refinement, tym łatwiejsze jest Planowanie Sprintu.

Refinement jest procesem iteracyjnym, co oznacza, że elementy backlogu mogą być wielokrotnie aktualizowane, gdy pojawia się nowa wiedza lub zmieniają się priorytety. Dzięki regularnemu doskonaleniu Backlogu Produktu zespoły zachowują elastyczność i mogą dostosowywać się do zmieniających się wymagań biznesowych, co jest istotnym elementem pracy w podejściu zwinnym (Agile). Możemy stopniowo rozbijać duże funkcjonalności na epiki, epiki na User Story i w końcu dzielić User Story na znacznie mniejsze niż wielkość pracy mieszczącej się w Sprincie (np. Velocity).

Cykliczna pielęgnacja Backlogu Produktu pozwala na zwinne przygotowywanie zakresu na kolejne Sprinty just in time w przeciwieństwie do podejścia Big Analysis Up Front w waterfallu. Dzięki temu możemy zacząć pracę nad produktem wcześniej i nie tworzymy zbędnej dokumentacji.

Bardzo przydatną metaforą na Refinement Backlogu Produktu jest góra lodowa. Product Backlog z natury ma mniejsze, gotowe do Sprintu elementy na górze, a im niżej schodzimy tym więcej jest większych elementów. Kiedy zabierzemy te elementy z samej góry backlogu do Sprintu, to nad powierzchnię wody wyłaniają się kolejne większe elementy, które znowu trzeba rozbić.

Główne cele Refinementu

Celem Refinementu jest zapewnienie, że Backlog Produktu pozostaje aktualny i uporządkowany, a jego elementy są gotowe do realizacji w nadchodzących Sprintach. Refinement pozwala na:

1. Przegląd Backlogu Produktu w krótkim horyzoncie czasowym
2. Rozbijanie dużych elementów backlogu na mniejsze, które mogą być zrealizowane w jednym sprincie.
3. Uszczegółowienie elementów tak, aby zespół miał pełną jasność co do oczekiwań. Na przykład przez doprecyzowanie Acceptance Criteria w User Story.
4. Obniżenie ryzyka związanego z niezrozumieniem lub niepewnością co do zakresu poszczególnych elementów. Bez tego Zespół Scrum zaplanował by pracę, która może znacznie się zmienić w Sprincie.
5. Oszacowanie elementów, co pomaga zespołowi lepiej planować pracę w najbliższych Sprintach. Zdarza się, że po rozbiciu i wyjaśnieniu zmienia się sumaryczna wielkość elementu.
6. Porządkowanie backlogu, dzięki czemu zespół koncentruje się na funkcjonalnościach o największej wartości dla produktu. Nawet po rozbiciu elementów może się okazać, że część mniejszych kawałków powinna jednak znaleźć się niżej na Backlogu Produktu.

Efektem Refinementu jest uporządkowany backlog w stanie gotowym do Sprintu, który wspiera płynną realizację Planowania Sprintu i minimalizuje ryzyko wystąpienia niejasności w trakcie pracy.

Kiedy odbywa się Refinement?

Zespoły najczęściej organizują Refinement jako dedykowane spotkanie lub serię krótkich spotkań rozproszonych w czasie trwania Sprintu. Refinement nie ma ściśle określonego miejsca w harmonogramie Sprintu, ale zgodnie z praktykami Scrum powinien być realizowany w każdym Sprincie. Refinement nie jest Wydarzeniem Scrumowym ponieważ nie ma określonego maksymalnego czasu trwania i jasno sprecyzowanych uczestników.

Pielęgnacja Backlogu Produktu to duży wysiłek mentalny, więc dobrą praktyką jest organizowanie go w pewnym odstępie od Wydarzeń Scrumowych. W praktyce najcześciej jest planowany w środku Sprintu. Seria krótkich spotkań będzie bardziej efektywna pod względem utrzymania skupienia uczestników, ale powoduje więcej przerwań w pracy wykonywanej w trakcie Sprintu. Jedno, dłuższe spotkanie to jednorazowe oderwanie Developerów od pracy, ale większe zmęczenie podczas spotkania.

Kilka spotkań daje nam również czas na znalezienie odpowiedzi na pytania Developerów, które pozostały otwarte po sesji.

Tak naprawdę to dowolna praca związana z porządkowaniem, uszczegóławianiem, przeglądaniem Product Backlog to refinement.

Ile trwa Refinement?

Do 2020 roku Scrum Guide zalecał, aby Refinement nie zajmował więcej niż 10% całkowitego czasu trwania Sprintu, co pozwala zespołowi na zachowanie równowagi między doskonaleniem backlogu a realizacją pracy zaplanowanej na dany Sprint. Jednak z jakiegoś powodu ten zapis zniknął. Dlaczego? Ponieważ czas potrzebny na pielęgnację backlogu zależy od wcześniejszego przygotowania Product Backlog i poziomu wiedzy w Zespole Scrumowym. Możliwe, że będzie potrzebne nawet 50% czasu Sprintu, żeby dobrze zrozumieć zakres planowany do wykonania w kolejnym Sprincie.

Czas poświęcony na Refinement można optymalizować poprzez utrzymanie dużego skupienia i zaangażowania na spotkaniu. Odpowiednia facylitacja spotkania będzie tutaj kluczowa. Odpowiednie przygotowanie także wpłynie pozytywnie. Można wcześniej poinformować uczestników co będzie tematem na najbliższym spotkaniu. Pokazywanie wysokopoziomowego obrazu  produktu jako wstęp pozwoli zbudować skupienie i przypomnieć kontekst rozmowy. Przywołanie Story Mapping czy chociażby Roadmapy produktu to bardzo dobry pomysł.

Kto uczestniczy w Refinemencie?

Refinement to proces zespołowy, w którym udział biorą Product Owner, Developerzy oraz, jeśli to konieczne, interesariusze. Product Owner odgrywa kluczową rolę, ponieważ to on odpowiada za Backlog Produktu i priorytetyzację jego elementów. Jego zadaniem jest wyjaśnienie wymagań, podzielenie się wizją produktu i zapewnienie zespołowi pełnej jasności co do celów poszczególnych zadań. Developerzy wnoszą wkład techniczny, analizując wykonalność zadań, identyfikując potencjalne ryzyka oraz szacując wielkość elementów Backlogu. W niektórych przypadkach zespół może również zaprosić ekspertów technicznych, analityków biznesowych lub innych interesariuszy, którzy mogą dostarczyć dodatkowego kontekstu i ułatwić zrozumienie bardziej złożonych zagadnień.

Kto prowadzi Refinement Backlogu?

Refinement nie ma formalnego prowadzącego, ale to Product Owner pełni główną rolę w tym procesie. Jest odpowiedzialny za:

• jasne sformułowanie elementów backlogu,
• wyjaśnienie priorytetów i wizji produktu,
• odpowiadanie na pytania zespołu, aby rozwiać wszelkie wątpliwości.

Scrum Master może wspierać proces Refinementu, szczególnie w zespołach początkujących, dbając o to, aby spotkania były zgodne produktywne. Scrum Master może również pomóc w zarządzaniu czasem oraz facylitacji spotkania, ale główny ciężar prowadzenia Refinementu spoczywa na Product Ownerze.

Kto uczestniczy w Refinemencie?

Pielęgnacja backlogu ma przede wszystkim za  zadanie jak najlepsze zrozumienie pracy do wykonania w nadchodzących Sprintach, identyfikację zależności i oszacowanie elementów. 

Przede wszystkim w takich spotkaniach biorą udział Developerzy. Product Owner prowadzi sesję i podejmuje decyzje na bieżąco, a Scrum Master dba o przebieg spotkania. Nic nie stoi na przeszkodzie, żeby w razie potrzeby zaprosić także interesariuszy. Jeżeli ktoś jest ekspertem w pewnej dziedzinie, to łatwiej i szybciej jest doprecyzować szczegóły z tą osobą. Moglibyśmy oczywiście traktować Product Ownera jako Single Point of Contact i kogoś kto wie wszystko, jednak takie podejście tworzy wąskie gardło i jest mniej efektywne.

Jeżeli zakres elementów omawianych bezpośrednio z interesariuszami rozrośnie się za bardzo, to pamiętajmy, że Product Owner ma ostateczna decyzję co i jakim stopniu zostanie zrealizowane przez Scrum Team.

Wyzwania związane z Refinementem

Mimo licznych korzyści Refinement może stanowić wyzwanie dla Zespołów Scrum, zwłaszcza tych mniej doświadczonych. Najczęstsze trudności obejmują przesadne skupienie na szczegółach, które może prowadzić do straty czasu i ograniczenia zasobów na realizację bieżącej pracy w Sprincie. Trzeba pamietać, że pielęgnacja backlogu ma nas przygotować do planowania. Nie schodzimy tutaj na poziom zadań i staramy sie zaplanować Sprintu. Jeżeli korzystamy z Velocity do określenia wydajności zespołu, to rozbicie elementów na takie wielkości 1/10 do 1/6 Velocity jest wystarczające i najbardziej rozsądne.

Brak zaangażowania zespołu  skutkuje niedostatecznym przygotowaniem elementów backlogu do realizacji. Jeżeli Developerzy nie zadają pytań to trudno jest upewnić się, że dobrze rozumieją zakres pracy. Oczywiście można w tym przypadku posiłkować się protezą w postaci analityka biznesowego, który przejmie na siebie obowiązek przygotowania elementów do Sprintu. Jednak po pierwsze taka sekwencyjna praca przypomina waterfall, a po drugie odpowiedzialność skupia się na jednej osobie zamiast całym zespole.

Dodatkowym problemem bywa niedopasowanie priorytetów między Product Ownerem a Developerami, co może prowadzić do napięć i spowolnienia procesu. Jeżeli Product Owner nie jest przygotowany, albo ciągle zmienia zdanie, to w końcu powstanie konflikt. Wyzwania te potęgują się przy problemach z estymacją pracochłonności/szacowaniem elementów backlogu, szczególnie w przypadku bardziej złożonych wymagań i wielu zależności.

Aby lepiej pielęgnować backlog Zespoły Scrum powinny regularnie omawiać proces Refinementu podczas retrospektyw i aktywnie poszukiwać sposobów na jego optymalizację.

Co z definition of Ready?

W niektórych materiałach o Scrumie możemy znaleźć koncepcję Definition of Ready. Jest to lista elementów jakie trzeba odhaczyć, żeby uznać element Backlogu Produktu za gotowy do Sprintu. Na przykład: wszystkie warunki satysfakcji określone, tekst do wklejenia napisany, ekran dostępny w postaci makiety itd.

Jednak ta praktyka nie pojawia się w Scrum Guide. Przy okazji zmian w 2020 roku odbyła się ożywiona dyskusja na ten temat. Twórcy Scruma uznali, że Scrum Guide ma się ograniczać do elementów i praktyk wymaganych w każdym kontekście. Więc nie ma potrzeby, żeby narzucać DoR w zespołach, które tego nie potrzebują.

Definiton of Ready może być przydatną praktyką, ale często obraca się w swojego rodzaju broń przeciwko Product Ownerowi. Developerzy traktują tą listę jako wymówkę, żeby odrzucać elementy backlogu i nad nimi nie pracować. Nie jest to dobre ani porządane podejście w Scrum.

Framework działa najlepiej, kiedy Zespół Scrumowy współpracuje i wspólnie bierze odpowiedzialność za dostarczenie wartości do klienta. W praktyce nie da się przygotować idealnych elementów i w trakcie wykonywania pracy i tak pojawią się pytania. Więc zwlekanie z podjęciem elementu nic nie zmienia oprócz wydłużenia Time to Market.

Podsumowanie

Refinement to nieformalny, ale istotny proces w Scrumie, który wspiera zespół w przygotowaniu elementów Backlogu Produktu do realizacji w nadchodzących Sprintach. Regularne i dobrze przeprowadzone Refinementy pomagają zespołowi uniknąć niejasności, lepiej zaplanować sprint i skoncentrować się na dostarczaniu wartości. Dzięki temu procesowi zespół może działać efektywnie, a Backlog Produktu pozostaje dynamiczny i aktualny, co zwiększa elastyczność w odpowiedzi na zmieniające się potrzeby biznesowe.