• Product Academy
  • Posts
  • Jak doświadczeni Product Managerowie robią backlog refinement?

Jak doświadczeni Product Managerowie robią backlog refinement?

Konkretne rady i techniki

Backlog refinement to jedno z najważniejszych spotkań w procesie tworzenia produktu. Z założenia proste, w praktyce - wiadomo, nie jest lekko. Czy robić, jak robić, a czego unikać?

Backlog refinement to jedno z tych spotkań, które może stać się albo kluczowym elementem efektywnej produktowej pracy w Scrumie, albo… totalnym marnowaniem Waszego czasu.

Spytaliśmy doświadczonych product managerów - jak oni podchodzą do backlog refinementów. Przechodzili już przez wiele wyzwania i wypracowali swoje sposoby na to, jak robić refinement lepiej. Poznasz ich ulubione techniki, przykłady dobrych praktyk i pułapki, których warto unikać.

1️⃣ Podziel Refinement na etapy

Kata Motyka praktykuje podzielenie refinementu na dwa oddzielne spotkania:

  • Refinement z PO – skupienie na zrozumieniu user stories, celów biznesowych, edge cases.

  • Tech refinement – sami developerzy pracują nad subtasks i estymacją.

„Mogą się odbyć tego samego dnia, ale nie muszą – to pomaga uniknąć przeciągania spotkania.”

Taki podział pozwala na bardziej efektywne wykorzystanie czasu zespołu. W pierwszej części koncentrujecie się na zrozumieniu wymagań i celów, co jest kluczowe dla biznesu. W drugiej części zespół może w pełni skupić się na aspektach technicznych, takich jak rozbicie zadań na mniejsze części czy estymowanie ich pracochłonności. Dzięki temu refinement staje się bardziej przejrzysty i produktywny.

Pro tip: Testuj różne modele podziału refinementu, dostosowuj liczbę i czas spotkań do dynamiki zespołu

2️⃣ Zespół jako driver procesu refinmentu

Według Damiana Milcza odpowiedzialność za refinement powinna być po stronie zespołu developerskiego:

„To oni są driverami refinementu, to spotkanie dla nich. Rola Product Ownera polega tutaj na przygotowaniu backlogu, a nie przewodzeniu spotkaniu.”

  • Oznacza to, że zespół developerski powinien aktywnie angażować się w proces refinementu i samodzielnie prowadzić dyskusje na temat zadań.

  • Product Owner dostarcza kontekst biznesowy i zapewnia, że backlog jest odpowiednio przygotowany, ale to zespół decyduje, jak rozwiązać problemy techniczne i organizacyjne.

  • Taki model zwiększa poczucie odpowiedzialności w zespole i buduje zaangażowanie.

Pro tip: Zbuduj w zespole poczucie odpowiedzialności za refinement, edukuj o jego wartości i dawaj przestrzeń do autonomii.

3️⃣ Nie rób Refinementu na Planningu

Kuba Paluch podkreśla, żeby nie robić refinmentu na scrum planningu:

„Do tego czasu wszystkie zadania powinny być już omówione i najlepiej wyestymowane”. Planning to czas na ustalenie priorytetów, nie na analizowanie szczegółów.

  • Refinement na planningu to jedno z najczęstszych błędów, które prowadzą do chaosu i marnowania czasu.

  • Planning powinien być spotkaniem decyzyjnym, podczas którego wybieracie zadania gotowe do realizacji w sprincie.

  • Brak odpowiedniego przygotowania przed planningiem może skutkować niepełnym zrozumieniem zadań i opóźnieniami w realizacji sprintu.

Pro tip: Zdefiniujcie sobie Definion of Ready dla zadań, do którego powinny prowadzić refinementy. Jeśli zadanie nie spełnia tych krytertiów - nie może zostać zaplanowane.

4️⃣ Twój główny obowiązek - pokazanie kontekstu kontekstu

Jak mówi Paweł Chochoł, Twoim kluczowym zadaniem powinny być dostarczenie zespołowi backgroundu biznesowego:

„Dlaczego do tego doszliśmy? Jakie mamy use cases? Makiety? Edge cases?”

  • Dostarczenie pełnego obrazu biznesowego pozwala zespołowi lepiej zrozumieć, dlaczego konkretne zadanie jest ważne i jakie cele biznesowe ma wspierać.

  • Bez tego kontekstu łatwo o błędne założenia, które mogą wpłynąć na jakość finalnego rozwiązania.

  • Dlatego dobrze jest sobie przygotować kontekstu biznesowy, mockupy czy opisy przypadków użycia.

Pro tip: Przygotuj materiały z wyprzedzeniem, pozwól zespołowi znaleźć i zdefiniować najlepsze rozwiązanie.

5️⃣ Wykorzystuj techniki wizualne np. event storming

Event Storming to propozycja od Ani Skibickiej, szczególnie skuteczna przy nowych produktach lub niskim poziomie wiedzy domenowej w zespole:

„PO modeluje proces ‘po swojemu’, a zespół dev przypisuje zdarzenia w systemie do ścieżki użytkownika lub logiki biznesowej”.

  • Techniki wizualne, takie jak Event Storming, ułatwiają zespołowi zrozumienie złożonych procesów i pozwalają na wspólne tworzenie modeli działania systemu.

  • Wspólne mapowanie procesów buduje wspólne rozumienie wymagań i minimalizuje ryzyko nieporozumień. Dzięki temu możecie szybciej zidentyfikować luki lub problemy w zadaniach.

6️⃣ Placeholdery i kategorie zadań

Kuba Paluch tworzy placeholdery z odpowiednią nazwą (kategorią) zadania, by szybciej pokzywać co będziemy refinmentować:

„Tworzenie placeholderów zadań jak tylko mamy świadomość, że dane zadanie będzie implementowane”. To pozwala uniknąć chaosu w backlogu.

  • Placeholdery to zarysy zadań, które można stopniowo rozwijać w miarę zdobywania nowych informacji.

  • Dzięki nim backlog staje się bardziej uporządkowany, a zespół ma lepszą świadomość nadchodzących priorytetów.

  • Super, jeśli takie zadania będa miały chociażby podstawowe informacje, jak cel biznesowy czy możliwe wyzwania pod które to zadanie zdefiniowaliśmy

Pro tip: Wprowadź proste kategorie, np. Goal, Current Research, Questions, Feature Assumptions.

7️⃣ Spisywanie ustaleń na bieżąco podczas spotkania refinementowego

Karolina Złotkowska wskazuje, że dobrze jej się sprawdza na bieżące dokumentowanie przebiegu dyskusji:

„Zapisywanie ustaleń i wniosków na udostępnionym ekranie, a potem ich podsumowanie. To pomaga uniknąć nieporozumień.”

  • Zapisywanie ustaleń na bieżąco pozwala zespołowi szybko sprawdzić, czy wszyscy rozumieją zadanie tak samo.

  • Udostępniony ekran ułatwia śledzenie zmian w czasie rzeczywistym i minimalizuje ryzyko przeoczenia ważnych szczegółów.

  • Podsumowanie na koniec spotkania to dodatkowy krok, który zapewnia pełną jasność.

Pro tip: Ustal rotacyjnego „skrybę” na spotkania, aby angażować cały zespół. Skryba ma za zadanie spisywać i podsumowywać dyskusję i podjęte decyzje.

8️⃣ Otwarta przestrzeń na pytania

Zbytnie narzucenie rozwiązania i zdefiniowanie jego szczegółów przez PO może zabić sens refinementu i zamienić się w sesje wycen zadań. Paweł Chochoł radzi, by dać zespołowi przestrzeń na podejmowanie decyzji i zadawanie pytań.

„Dawajmy zespołom przestrzeń do pytań doszczegóławiających i upewniajmy się, że tak samo rozumiemy zadania”.

  • Zbytnie narzucanie rozwiązania spowoduje, że zespół może przestać angażować się w rozwój produktu.

  • Pytania doszczegóławiające są nieodłącznym elementem refinementu. Dają zespołowi możliwość wyjaśnienia wątpliwości i upewnienia się, że zadanie jest jasno określone.

  • Warto zachęcać do zadawania pytań i tworzyć atmosferę, w której każdy czuje się komfortowo, dzieląc się swoimi obawami czy pomysłami.

Pro tip: Swoje pomysły spisuj w formie hipotez, zaznaczaj, że to tylko potencjalne rozwiązania i czekasz na inne pomysły.

Nie ma uniwersalnej metody refinementu – wszystko zależy od specyfiki zespołu i produktu. Z doświadczenia wiemy, że żadna metoda nie jest uniwersalna. Ale jeśli spróbujesz jednej z opisanych technik, jest duża szansa, że Twój zespół Ci podziękuje. Polecamy przede wszystkim testować różne podejścia i regularnie sprawdzać, co działa najlepiej.

A jakie techniki sprawdzają się u Ciebie? Podziel się swoimi doświadczeniami w komentarzach!