Wyobraź sobie, że siedzisz na Sprint Planningu i ktoś pyta: “A czy zrobiliśmy grooming?” Połowa sali kiwa głową, druga połowa milczy, bo nie jest pewna, czy to pytanie o spotkanie, o listę zadań, czy może o coś, co powinno było się odbyć tydzień temu. W wielu zespołach grooming istnieje jako słowo, za którym kryje się zupełnie inna praktyka – albo nie kryje się nic.
Skąd pochodzi termin i dlaczego zniknął z oficjalnej dokumentacji
Słowo “grooming” pojawiło się w żargonie scrumowym mniej więcej wraz z pierwszymi wersjami Scrum Guide Schwabera i Sutherlanda z lat 2010–2011. Nawiązywało do pielęgnacji – podobnie jak się “czyści” i “porządkuje” Product Backlog przed kolejnym sprintem. Brzmiało niewinnie, do momentu, kiedy część środowiska anglojęzycznego zaczęła wskazywać, że słowo “grooming” ma w języku angielskim znacznie ciemniejsze konotacje. W 2013 roku strona scrumguides.org odnotowała oficjalną zmianę: Product Backlog jest odtąd “refined”, a nie “groomed”. Termin “refinement” nie jest więc modą – to świadoma decyzja twórców frameworku, zarejestrowana w sekcji revisions na scrumguides.org. Mimo to w polskich firmach IT słowo “grooming” trzyma się mocno i pewnie trzymać się będzie jeszcze przez lata, bo tak po prostu wszyscy mówią w pokoju obok.
Czym jest refinement – i dlaczego Scrum Guide nie nazywa go ceremonią
Scrum Guide w wersji z 2020 roku definiuje Product Backlog Refinement jako ciągłą aktywność – “ongoing activity” – polegającą na dzieleniu i precyzowaniu elementów backlogu, tak żeby były gotowe do Sprint Planningu. To ważne rozróżnienie: refinement nie jest czwartą ceremonią Scruma obok Daily, Review i Retrospective, choć w wielu zespołach funkcjonuje właśnie jako regularne, zaplanowane spotkanie. Scrum Guide nie narzuca jego formatu ani częstotliwości, wskazuje jedynie, że Product Owner i zespół deweloperski powinni poświęcać na tę aktywność nie więcej niż 10% czasu sprintu. W praktyce ta granica jest raczej teoretyczna – jedne zespoły siedzą na refinemencie trzy godziny w tygodniu, inne wpadają na kwadrans przed Planningiem i zastanawiają się, co właściwie mają wycenić.
Sam Mike Cohn w “Agile Estimating and Planning” zwracał uwagę, że dobrze pielęgnowany backlog to taki, w którym kilka najbliższych sprintów ma pozycje już opisane, podzielone i z grubsza wycenione. Nie chodzi o to, żeby cały backlog był gotowy na rok do przodu – takie podejście bardziej przypomina tradycyjny waterfall niż Agile. Chodzi o horyzont: Product Owner powinien mieć gotowych kilka User Stories do przodu, żeby Sprint Planning nie zamieniał się w improwizację.
Co konkretnie dzieje się podczas refinementu
Podczas typowej sesji refinementu Product Owner przedstawia elementy backlogu, które planuje wprowadzić do jednego z kolejnych sprintów. Zespół zadaje pytania, rozbija duże zadania na mniejsze, ustala kryteria akceptacji i szacuje pracochłonność – najczęściej w story pointach albo za pomocą Planning Pokera. Zdarzają się sytuacje, gdzie pozycja trafi na refinement po raz trzeci z rzędu, bo za każdym razem wychodzą nowe pytania bez odpowiedzi. To raczej sygnał, że User Story jest źle napisana albo że Product Owner nie zdążył porozmawiać z interesariuszem przed spotkaniem, nie że zespół jest nieefektywny.
Sprawdź, jak wygląda zarządzanie backlogiem w firmie – bo refinement bez dobrze utrzymanego backlogu to trochę jak przeglądanie szafy, z której połowę rzeczy nikt nie pamięta, kiedy powiesił. Efekt Parkinsona działa tu wyjątkowo sprawnie: ile czasu przeznaczysz na spotkanie, tyle spotkanie trwa – i nie zawsze ma to związek z tym, ile pracy faktycznie było do zrobienia.
Grooming w SAFe i większych organizacjach
W środowiskach korporacyjnych, gdzie Scrum działa w ramach Scaled Agile Framework (SAFe), refinement nabiera szerszego wymiaru. Obok Product Backlog Refinementu na poziomie zespołu pojawia się praca na poziomie PI Planning (Program Increment Planning) i backlogu programowego. Tam refinement przestaje być godzinnym spotkaniem, a staje się ciągłym procesem angażującym Product Managera, System Architect i kilka Agile Release Trainów jednocześnie. Dla kogoś, kto dopiero przerabia podstawy Scruma, to może brzmieć jak żargon rodem z Gwiezdnych wojen – i trochę właśnie tak to działa w praktyce.
Jeśli zastanawiasz się, jak grooming wpisuje się w szerszy kontekst ról i odpowiedzialności w projekcie Agile, zajrzyj do artykułu o rolach w projekcie Agile – bo spory o to, kto właściwie powinien prowadzić refinement, to jeden z tych tematów, które pojawiają się w niemal każdym zespole po pierwszych dwóch sprintach.
Czy refinement “działa” zależy w dużym stopniu od tego, czy Product Owner naprawdę rozumie biznes i ma dostęp do interesariuszy między sprintami. Bez tego spotkanie zamienia się w sesję zgadywania – a zgadywanie w Scrum ma przynajmniej tę zaletę, że dość szybko wychodzi na jaw podczas Sprint Review.
Zrodla
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Cohn M., “Agile Estimating and Planning”, Prentice Hall, 2005.
- Scrum Guide Revisions, scrumguides.org/revisions.html – zapis zmian terminologii grooming/refinement od 2013 roku.
Zdjęcie: Makayla Larner / Unsplash
