Co powinieneś wiedzieć o Product Backlog Refinement (Grooming)

Aby w Scrum w ogóle można było zaplanować Sprint i rozpocząć pracę, Product Backlog musi być dobrze zadbany i wypełniony odpowiednio przygotowanymi elementami Product Backlogu. Logiczne zatem, że regularnie trzeba przeprowadzać Refinement w Backlogu – ale jak to właściwie działa?

Czym dokładnie jest Product Backlog Refinement, na co powinieneś zwrócić uwagę i dlaczego Refinement jest tak ważny, wyjaśnimy Ci w tym artykule.

Co oznacza Product Backlog Refinement w Scrum?

Jeszcze niedawno w Scrum Product Backlog Refinement nazywał się Backlog Grooming (grooming po angielsku: pielęgnowanie). Backlog Refinement polega bowiem na pielęgnowaniu i przygotowywaniu Product Backlogu z jego elementami i Epicami tak, aby zespół Scrum mógł go używać jako podstawy do Sprint Planningu.

Product Backlog Refinement oznacza więc: elementy Product Backlogu są opracowywane, szacowane i priorytetyzowane w taki sposób, aby zespół deweloperski mógł z nich złożyć swój Sprint Backlog. Zadbany Product Backlog powinien zawierać zawsze w zapasie przynajmniej tyle przygotowanych elementów Product Backlogu, żeby można było zaplanować z nich kompletny Sprint.

Nadrzędnym celem Backlog Groomingu jest to, aby zespół deweloperski rozumiał wizję produktu Product Ownera i stworzone przez niego User Stories, dzięki czemu jest w stanie zaplanować kolejny Sprint zgodnie z celami Sprintów.

Przy okazji: Szukając pojęcia Refinement w Scrum Guide, można stwierdzić, że nie należy ono do oficjalnych wydarzeń Scrum, takich jak np. Sprint czy Daily Scrum. Product Backlog Refinement jest raczej tzw. Aktywnością, która odbywa się jako spotkanie. Oprócz Product Ownera i zespołu deweloperskiego w spotkaniu Refinement uczestniczy Scrum Master oraz – szczególnie przy strategicznych Refinementach – interesariusze.

Jak przebiega spotkanie Backlog Refinement

Przed właściwym Backlog Refinementem jest przygotowanie:

1. Product Owner ustala cel Sprintu (Outcome).
2. Zgodnie z tym celem Sprintu PO priorytetyzuje Product Backlog i wybiera najważniejsze elementy Product Backlogu (PBIs) lub pisze nowe.
3. Zespół Scrum formułuje wspólnie Definicję Gotowości (DoR), która określa, jakie cechy lub jaki poziom szczegółowości te elementy Product Backlogu muszą mieć, aby zespół deweloperski mógł je włączyć do Sprintu.

Teraz można przystąpić do przeprowadzenia spotkania Backlog Refinement:

1. Product Owner i zespół deweloperski omawiają cele Sprintu i powiązane z nimi PBIs. Ważne jest przy tym, żeby PO komunikował jedynie cel do osiągnięcia i nie narzucał sposobu jego realizacji.
2. Zespół deweloperski wnosi swój wkład. Obejmuje to z jednej strony własne pomysły na wdrożenie oparte na znajomości aplikacji lub produktu, z drugiej strony uwagi dotyczące technicznych zależności między PBIs, po których niektóre tematy są ponownie priorytetyzowane.
3. Gdy tylko zespół deweloperski i PO osiągną wspólne zrozumienie dotyczące elementu Product Backlogu, PO lub członek zespołu dokumentuje ten PBI zgodnie z DoR sformułowaną w punkcie 3 i zapisuje np. kryteria akceptacji. Wiele zespołów przeprowadza w tym miejscu również szacowanie nakładu pracy – nazywają to wtedy Estimation Poker, a nie Planning Poker, ponieważ nie odbywa się to w Planningu.

Product Backlog Refinement (Grooming) jest ważny dla sukcesu

Dobry Product Owner traktuje Refinement bardzo poważnie. Wie, że regularnie i rzetelnie przeprowadzany Backlog Grooming kładzie fundamenty pod przebieg późniejszego Sprintu, a tym samym pod sukces produktu, ponieważ:

• Refinement zapewnia, że Product Backlog jest aktualny i może być używany jako podstawa do następnego Sprint Planningu.
• Dzięki tej formie przygotowania zespół deweloperski zapoznaje się z najważniejszymi PBIs na wczesnym etapie i może zadawać pytania, które inaczej pojawiłyby się dopiero na Sprint Planningu. Daje to PO możliwość znalezienia odpowiedzi w odpowiednim czasie na spotkanie Planningu.
• Spotkania Sprint Planningu stają się krótsze, ponieważ trzeba teraz omawiać jedynie „Jak" realizacji, skoro „Co" zostało wyjaśnione przez Refinement. Ponadto PBIs zostały w idealnym przypadku już oszacowane przez zespół i mogą być dobierane zgodnie z Velocity. W ten sposób unika się sytuacji, gdy na Sprint Planningu nie ma wystarczającej liczby przygotowanych PBIs.
• Poprzez wspólne zajmowanie się PBIs PO i zespół deweloperski szybciej rozwijają wspólne rozumienie wizji, celów i zadań.
• Wszystkie pomysły zespołu deweloperskiego dotyczące realizacji PBI są podczas Refinementu zapisywane.
• Następuje ogromny transfer wiedzy, ponieważ PO przekazuje zespołowi poprzez Refinement coraz więcej kontekstu dotyczącego klientów, modelu biznesowego itp.
• Podczas Sprintu zespół może skupić się mocniej na właściwej pracy, ponieważ najważniejsze pytania zostały wyjaśnione w Refinemencie.

Na to powinieneś zwrócić uwagę przy Product Backlog Refinemencie!

1. Zanim będziesz mógł ostatecznie priorytetyzować lub porządkować PBIs w Product Backlogu, powinieneś mieć poczucie zakresu poszczególnych elementów, ponieważ to on determinuje koszty, które z kolei wpływają na priorytet. Zakres jest szacowany w Scrum w relatywnych jednostkach miary, takich jak Story Points.
2. Scrum nie narzuca, kiedy i jak często należy przeprowadzać Product Backlog Refinement. Nasza rekomendacja brzmi: 1 x w tygodniu, np. w środku Sprintu. Niektóre zespoły przeprowadzają zamiast tego codzienne, ale za to krótsze Refinementy, co w dużej mierze zależy od dostępności Product Ownera.
3. Jak w przypadku wydarzeń i innych Aktywności w Scrum, również przy Product Backlog Refinemencie zalecane jest regularne przeprowadzanie według stałego rytmu, aby wyrobić rutynę.

Podsumowanie dotyczące Product Backlog Refinementu

Regularne i staranne Product Backlog Refinement jest absolutnie niezbędne do pomyślnego przebiegu Sprintu – a tym samym do sukcesu produktu. Jeśli już pracujesz jako Product Owner lub chcesz przygotować się do tej ekscytującej roli i ćwiczyć Product Backlog Refinement w praktyce, chętnie wesprzemy Cię odpowiednim szkoleniem dla Product Ownerów.

Pobierz szablon Backlog Refinement