W spisie treści Przewodnika po Scrumie trudno doszukać się słowa „refinement”. Nie ma go w sekcji „Wydarzenia w Scrumie”. Zatem jest obowiązkowy czy nie? Otóż, refinement to nie wydarzenie, spotkanie itd., to proces. Rzecz jasna, można upierać się, że w kalendarzu mamy spotkanie, ale w praktyce nie jest to pojedyncza akcja, a ciągłe działanie na rzecz udoskonalania Product Backlogu.
O Product Backlogu przeczytasz więcej w tym artykule: Artefakty Scruma cz.1 – Backlog Produktu
Refinement w Przewodniku o Scrumie
Przewodnik po Scrumie w miejscu opisu (wersja polska, strona 8) Sprintu określa, że w jego trakcie „Product Backlog jest w razie potrzeby uszczegóławiany”. To oznacza, że w czasie pojedynczej iteracji zespół pracuje nad udoskonaleniem, doprecyzowaniem, estymacją.
Dalej, na stronie 11 czytamy:
Elementy Product Backlogu, które mogą zostać Ukończone przez Scrum Team w trakcie jednego Sprintu, zostają uznane za gotowe do wybrania podczas Sprint Planningu. Zwykle osiągają ten stopień przejrzystości w procesie ich doskonalenia. Doskonalenie (ang. refinement) Product Backlogu to działanie polegające na dzieleniu elementów Product Backlogu na mniejsze, bardziej precyzyjnie zdefiniowane jednostki oraz na ich dookreślaniu. To ciągły proces, którego celem jest dodawanie szczegółów, takich jak opis, kolejność czy rozmiar.
I to by było na tyle, jeżeli chodzi o opis procesu doskonalenia w biblii Scruma. Wydarzeń jest zatem pięć, a refinement nie jest jednym z nich. Określanie go jako spotkania, przyjęło się w ramach dobrych praktyk, bo przecież i tak w momencie, kiedy opisujemy i doprecyzowujemy zadania z kimś, potrzebujemy terminu w kalendarzu. Takie przyzwyczajenie nie jest oczywiście niczym złym, ale należy pamiętać, że to nie jedyna możliwość na dbanie o Product Backlog.
Refinement, czyli proces doskonalenia Product Backlogu
Doskonalenie Product Backlogu trwa w Sprincie prawie cały czas. W Przewodniku możemy przeczytać, że każde powinno osiągnąć pewien stopień przejrzystości. Oznacza to, że w tym procesie zawierają się na przykład takie czynności:
- dzielenie elementów Product Backlogu na mniejsze części (tak, by dało się każdą z nich zmieścić podczas pojedynczego Sprintu),
- określanie szczegółów zadań (np. poprzez tworzenie opisów, kryteriów akceptacji, definiowanie wyglądu produktu itd.),
- estymowanie,
- ustalanie kolejności elementów (priorytetów) Product Backlogu.
Scrum Team nie zawsze jest w stanie osiągnąć wspomnianą przejrzystość zadań podczas pojedynczego spotkania. Wielokrotnie spotykałam się z tym, że postawione pytania trzeba było zweryfikować, przedyskutować z interesariuszami lub po prostu zgromadzić więcej wiedzy na ich temat. Z tego powodu, refinementem nazywa się całość działań podejmowanych na drodze doprowadzenia elementów Product Backlogu do zadowalającego stanu.
Najczęstsze praktyki związane z doskonaleniem
W poprzednich akapitach zaznaczyłam, że najczęściej pomyłki w zaliczaniu refinementu do wydarzeń w Scrumie wynikają z tego, iż ma on swoje miejsce (nierzadko stałe) w kalendarzu. Samo posiadanie spotkania o takiej nazwie nie jest błędem!
Refinement jako spotkanie powtarzające się
Wiele zespołów, które znam lub z którymi miałam okazję pracować chce ustalać stałe spotkania na doskonalenie, bo nadaje to pewien rytm ich pracy. Dzięki stałej porze można się odpowiednio przygotować – przeczytać wymagania, zastanowić się nad potencjalnymi pytaniami. To oczywiście nie oznacza, że nic poza tymi spotkaniami się nie dzieje – najczęściej Product Owner doprecyzowuje treść elementów Product Backlogu wcześniej. Wtedy także PO może przygotować się do rozmowy, czy przedstawienia swojej wizji w sposób zrozumiały dla wszystkich.
W spotkaniach dotyczących doskonalenia nie musi uczestniczyć cały Scrum Team. Przede wszystkich mam na myśli Developerów, którzy mogą „wysłać” na spotkanie tylko te osoby, które mają wiedzę lub są potrzebni. Ma to zastosowanie szczególnie przy dużych zespołach.
Refinement bez spotkań
Ciężko mi sobie wyobrazić procesy doskonalenia bez pracy Scrum Teamu, który spotyka się fizycznie lub umawia video rozmowę przez jeden z komunikatorów. Wiem jednak, że takie procesy mają miejsce. Doskonalenie odbywa się asynchronicznie, cała grupa wymienia się informacjami poprzez pisanie e-maili lub wiadomości np. na Slacku.
Mimo, że nie uczestniczyłam w takim procesie myślę, że jest to całkiem sensowne rozwiązanie. Wymaga jednak sporej dyscypliny i wysokiego poziomu transparentności, by nic, co dotyczy zadania nie umknęło w tej wymianie zdań.
Refinement jako spotkanie do wykonywania estymacji
Spotkałam się z podejściem, że na refinement Product Owner przygotowywał zadania bardzo dokładnie. Uzupełniał opis i wszystkie inne wartości, pozostawiając jedynie estymacje do wykonania. Jest to dobra technika, lecz o ile estymacja jest częścią doskonalenia Product Backlogu, o tyle nie powinna być jedynym jej elementem. Nawet, gdy elementy do omówienia są dokładnie rozpisane i zespół zapoznał się z nimi wcześniej, powinna być utworzona przestrzeń do wyjaśnienia wizji stojącej za tym kawałkiem produktu. Tak, by każdy miał pewność, że nie ma tu niedomówień i miejsca na domysły.
O samym estymowaniu przeczytasz w naszych artykułach:
- Jak estymować? cz. 1 – teoria
- Jak estymować? cz. 2 – techniki estymacji
- Jak estymować? cz. 3 – Team estimation game
- Estymacje kontra zadania przechodzące na kolejny sprint
Wszyscy doskonalimy razem
Znam zespoły, które pracują nad Product Backlogiem zawsze wspólnie. Przed spotkaniem tworzone są ogólne opisy, czasami tylko tytuły, a podczas wspólnego doskonalenia dodawane są pozostałe elementy. To podejście jest na pewno bardziej kosztowne – wymaga od wszystkich zaangażowania i czasu. No i nie da się zapewne wszystkiego wyjaśnić od razu, bo nikt wcześniej nie wiedział o czym będzie mowa.
Research jako element refinementu
W pewnym momencie pracy z zespołami doszłam do konkluzji, że zadanie typu research czy spike też jest elementem procesu refinementu. Robi się je po to, by wyklarować zakres, technologię, przydatność i wiele innych obszarów, które nie pozwalają nam przystąpić do realizacji zadania. Takie poszukiwania odpowiedzi mogą przynieść bardzo różne rezultaty, ale zdecydowanie mają wpływ na późniejszą wartość czy estymację konkretnych elementów Product Backlogu.
Podsumowanie
Refinement to bardzo potrzebny proces, wręcz wymagany, by Product Backlog można było nazwać uporządkowanym i transparentnym. Nie jest jednak sprecyzowane, jak Scrum Teamy powinny to robić – ta część należy już do ich interpretacji. Każda technika refinementu prowadząca do stworzenia przejrzystych zadań, zrozumiałych dla wszystkich członków zespołu i interesariuszy, jest pożądanym efektem działań doskonalących.
Sprawdź nasze ostatnie wpisy:
- Liberating Structures: zwinne narzędzia dla lepszej współpracy
- Kluczowe umiejętności – Agile Coach
- Rozgrzewka przed retrospektywą