Podczas refinementu zapadają decyzje o tym, jak przekuć pomysły biznesowe na funkcje produktu i jak sprawdzić hipotezy o potrzebach klientów. To tutaj pojawiają się koncepcje na architekturę rozwiązań, toczą dyskusje o zależnościach z innymi zespołami i razem z nimi. Wspólne pielęgnowanie Backlogu w Zespole Scrumowym daje możliwość realnego wpływu na kształt produktu, buduje zaangażowanie, umożliwia wymianę wiedzy i kompetencji. Pod warunkiem, że refinement… odbywa się regularnie i porządnie zarazem.
Jak sprawdzić, czy sesje doskonalenia Rejestru Produktu powinny odbywać się częściej i przebiegać inaczej?
W Scrum Guide przeczytacie, że doskonalenie Rejestru Produktu jest procesem ciągłym, który nie powinien zajmować więcej niż 10% czasu sprintu, czyli ok 3,5 h na tygodniowy Sprint. Sporo, szczególnie, jeśli dodamy do tego, albo odejmiemy od czasu przeznaczonego na realną pracę nad zadaniami, czas poświęcony na zdarzenia Scrumowe. Refinement charakteryzuje duża dowolność, jak na zasady Scruma, które precyzyjnie określają spotkania, ich przebieg i timeboxy. Patrząc z tej perspektywy, jest elementem metody, który wymyka się jej przewidywalnym, skrupulatnym ramom. Być może właśnie dlatego bywa traktowany marginalnie, podczas gdy jest newralgicznym elementem Scruma.
Co jest celem doskonalenia Backloga?
Odpowiedź wydaje się oczywista – uporządkowany Backlog, czyli taki, który zawiera opisane, oszacowane i spriorytetyzowane elementy, gotowe do zaplanowania w kolejnych Sprintach. To zaledwie część prawdy.
Wyobraźcie sobie sytuację, w której to Product Owner samodzielnie, bazując na swoich pomysłach, skrupulatnie i regularnie wpisuje w Backlog jego kolejne elementy. Równie regularnie spotyka się z Zespołem Deweloperskim na wspólnych sesjach doskonalenia Backlogu, podczas których prezentuje efekt swojej pracy, a zespół estymuje wielkość zadań, korzystając z ciągu Fibonacciego lub dowolnej innej metody szacowania. Backlog wygląda świetnie, ale czy świetny jest proces doskonalenia Backlogu? Nie bardzo. Uważam, że takie działanie to jeden z błędów, popełnianych przez Product Ownerów. Tajemnica sukcesu partnerskiej współpracy Product Ownera z Zespołem Deweloperskim polega na połączeniu dwóch perspektyw – biznesowej z technologiczną. Product Owner określa, co chce osiągnąć, a następnie wspólnie z zespołem ustala, w jakich krokach najlepiej to zrobić.
Celem doskonalenia Rejestru Produktu jest wspólne wypracowanie w Zespole Scrumowym rozwiązań, które w sposób optymalny łączą odpowiedź na potrzebę biznesową z inżynierskim kunsztem. Product Owner odpowiada za to, “CO” ma być efektem prac, a do dyskusji o tym, “JAK” to osiągnąć, zaprasza swój zespół.
W ramach sesji doskonalenia Backloga Produktu, w zależności od potrzeb, mogą również odbyć się m.in:
- Warsztatowa forma rozpoznania potrzeb klienta, typu Product Discovery
- Ustalenie zależności pomiędzy nowym rozwiązaniem a aktualnym ekosystemem
- Uzgodnienie architektury rozwiązania
- Konsultacje z innymi zespołami/ wspólne zaprojektowanie rozwiązania
- Warsztatowe spotkanie produktowe z elementami technik UX
Jak sprawdzić, czy refinement jest “porządny”?
Można zajrzeć do Rejestru Produktu i sprawdzić jakość jego elementów. Przepracowany Backlog nie jest jednak wartością samą w sobie. O tym, czy zespół odpowiednio dobrze realizuje refinement świadczy w jakimś stopniu jakość produktu. Na ile odpowiada na potrzeby klientów? Czy jest prosty w obsłudze, intuicyjny? Czy jest stabilny? Ważniejsze od tego, jak wygląda Rejestr Produktu, jest również to, czy jest wygodnym narzędziem pracy dla Zespołu Scrumowego. Można z niego wyczytać kierunek rozwoju produktu? Jego elementy są zrozumiałe i łatwo z nich korzystać podczas Planowania? W przypadku wątpliwości w trakcie Sprintu można do niego zajrzeć, żeby upewnić się, co i po co ma zostać wykonane? A co z morale zespołu? Cały Zespół Scrumowy czuje się odpowiedzialny za produkt, identyfikuje się z rozwiązaniami, które przygotowuje, czy może jest jedynie wykonawcą pomysłów, które przychodzą „z góry”?
Podsumowując, jeśli produkt jest świetny, zespół zmotywowany i zapalony do pracy, a Backlog wygodny w użyciu oraz zrozumiały, zespół idealnie realizuje refinement. Jeśli natomiast któryś z wymienionych elementów szwankuje, albo mógłby wyglądać lepiej, warto bliżej przyjrzeć się sesjom doskonalenia Backloga w zespole.
Podczas jednego ze szkoleń z podstaw Scruma Dawid i Kuba, omawiając, na czym polega refinement, stworzyli coś na kształt “błędnego koła”, w jakie wpada część Zespołów Scrumowych. Sprawdźcie, czy rozpoznajecie podobne zjawiska w Waszym Scrumie.
Papierkiem lakmusowym tego, czy zespołowi przyda się refinement w lepszym i prawdopodobnie częstszym wydaniu, jest również to, co dzieje się podczas zdarzeń Scrumowych oraz w trakcie Sprintu Na grafice pokazałam przykładowe objawy, które mogą świadczyć o tym, że warto podyskutować w zespole o częstotliwości i jakości sesji doskonalenia Backloga.
Kiedy robić refinement?
Sesje doskonalenia Backloga mogą mieć swój stały rytm w ramach cyklu Scrumowego (zawsze ten sam dzień i godzina), być ustalane podczas planowania albo na bieżąco w trakcie Sprintu. Pierwsze rozwiązanie ułatwia zespołowi zaplanowanie i zorganizowanie pracy, ale jednocześnie wprowadza element rutyny, który niekoniecznie musi odpowiadać realnym potrzebom w Sprincie. Rozwiązania drugie i trzecie wymagają każdorazowo uzgodnień pomiędzy Product Ownerem a Zespołem Deweloperskim, ale zarazem częściej inicjują rozmowy o tym, co będzie przedmiotem dyskusji podczas refinementu, żeby odpowiednio dopasować termin, uczestników i czas trwania spotkania. Dzięki temu sesje mogą przebiegać efektywniej i być krótsze.
Najczęstsze rozwiązania to:
- ustalony rytm dłuższych spotkań (jedno lub dwa w trakcie Sprintu)
- ustalony rytm krótkich, np. półgodzinnych spotkań tuż przed lub po daily
- spotkania uzgadnianie ze Sprintu na Sprint, długość których jest dostosowana do aktualnych potrzeb w zespole
Na co jeszcze warto zwrócić uwagę?
Jak w większości przypadków i tutaj diabeł tkwi w szczegółach. Zebrałam dla Was kilka takich, które wpływają na to, czy refinement sprzyja konstruktywnym dyskusjom i przekłada się na lepsze efekty pracy zespołu.
- Materiały (np. dane, gotowe rozwiązania, z których można skorzystać)
Doskonalenie Backloga Produktu to idealny czas na to, żeby zastanowić się, z jakich danych, metryk, materiałów, czy źródeł wiedzy warto skorzystać, dyskutując o nowych rozwiązaniach. W wielu zespołach część pracy jest dublowana m.in. dlatego, że zbyt mało uwagi poświęca się na chwilę refleksji o tym, z czego już można skorzystać.
- Odpowiedni dobór uczestników
Na to spotkanie możecie zaprosić każdego, kto ma potencjał, by wnieść wartość do omawianego tematu – osoba z zespołu, z którym współpracujecie, odbiorca rozwiązania, interesariusz czy ekspert dziedzinowy. Praktyka prosta i skuteczna, ale nie zawsze oczywista.
- Schemat zadań i ustaleń
Niezależnie od tego, czy stosujecie schemat historyjki (ang. User Story), warto ustalić w zespole standardy zadań, które porządkują ustalenia i notatki oraz wspierają standardy jakości zespołu. Do najważniejszych należą Kryteria Akceptacji oraz Definicja Gotowości
- Odpowiedni dobór formy spotkania
Sesje doskonalenia Backlogu Produktu mogą odbywać się w dowolnej formie. Ważne, aby była ciekawa i angażująca. W zależności od tematu i etapu pracy nad nim, możecie korzystać z elementów warsztatowych, technik UX, jak mapa empatii, user journey, czy elementów Design Thinking albo sprawdzonych technik produktowych, jak story mapping
- Wyprzedzenie, z jakim są omawiane tematy
Nawet najlepsze spotkanie, z dobrze opisanymi historyjkami nie pomoże, jeśli pomiędzy realizacją tematu, a jego omawianiem minie za dużo czasu. Oprócz tego, że zespół może zapomnieć szczegółowy kontekst zadań, mogą zmienić się zależności, co spowoduje, że część pracy koncepcyjnej trzeba będzie wykonać jeszcze raz.
Więcej informacji o tym, jak zorganizować efektywną sesję doskonalenia Rejestru Produktu znajdziecie w dedykowanym materiale Pomocy, nasz refinement nie działa!
O Refinemencie i Porządnym Backlogu Produktu możecie też posłuchać w podcaście „Porządny Agile” autorstwa Kuby Szczepanik i Jacka Wieczorka.