Blog

Pielęgnacja ma doprowadzić Backlog Produktu do stanu, dzięki któremu Zespół Scrum będzie w stanie zaplanować najbliższy Sprint. Efektem skutecznej pielęgnacji jest więc dobre zrozumienie przez cały Zespół, jakie elementy znajdują się na szczycie Backlogu, dlaczego tam się znalazły i skąd się wzięła taka, a nie inna ich kolejność.

Aby dało się zaplanować Sprint, elementy w górnej części Backlogu Produktu powinny być:

• na tyle małe, by dało się je zrealizować w czasie jednego Sprintu,
• wystarczająco zrozumiałe dla Developerów, by byli w stanie zaplanować ich realizację.

Pielęgnacja wystarczająca, ale minimalna

Celem pielęgnacji nie jest uzyskanie pewności, że coś się da zrobić – tego w prawdziwie zmiennym i nieprzewidywalnym środowisku osiągnąć się nie da. Pielęgnacja powinna zatrzymać się w momencie, kiedy Zespół wie już wystarczająco dużo, by zaplanować realizację poszczególnych elementów Backlogu Produktu.

W czasie pielęgnacji powinno się zwracać uwagę na zależności, które muszą zostać zaspokojone, aby development poszczególnych zmian w produkcie był możliwy. To pozwala Product Ownerowi uporządkować Backlog tak, by zależności te wyeliminować albo przynajmniej ograniczyć. Przy czym i tu należy uważać, by nie wpaść do studni niekończących się analiz w złudnym dążeniu do uzyskania planu gwarantującego bezproblemowy development.

Dyskusja o detalach implementacyjnych i planowanie konkretnych działań Developerów odbywać się powinna dopiero na Planowaniu Sprintu. To pozwala uniknąć zmarnowania wysiłku włożonego w te elementy Backlogu Produktu, które Product Owner ostatecznie usunie z listy (a przecież może zrobić to w każdej chwili). Podobne marnotrawstwo będzie miało miejsce, jeśli z jakiegoś powodu takie szczegółowo opisane elementy będą musiały zostać zmienione, przez co poczynione wcześniej detaliczne ustalenia staną się nieaktualne.

Budowany z dużym wyprzedzeniem plan realizacji poszczególnych elementów Backlogu Produktu może również kotwiczyć Developerów przy konkretnym rozwiązaniu, które wydawało się im najlepsze w momencie przeprowadzania pielęgnacji. Mogą oni trzymać się go nawet wtedy, gdy pojawią się nowe możliwości pozwalające przeprowadzić realizację o wiele efektywniej. A niewykluczone, że w ogóle nie nastąpi walidacja poczynionych wcześniej ustaleń i Sprint rozpocznie się z założeniem, że „wszystko wiadomo”. Skutki takiej aroganckiej strategii są zazwyczaj katastrofalne.

W pielęgnacji nie chodzi również o to, by uzyskać odpowiedzi na wszystkie pytania związane z poszczególnymi elementami Backlogu Produktu. Konieczne jest wyjaśnienie kwestii kluczowych i najbardziej ryzykownych, które mają istotny wpływ na ilość pracy i kolejność jej wykonywania. Uzyskanie odpowiedzi na mniej ważne pytania może stanowić po prostu jeden z etapów realizacji. W ten sposób większość pracy związanej z konkretnym elementem Backlogu Produktu odbywa się w iteracji, w której element ten jest realizowany, a nie w Sprintach wcześniejszych, zjadając czas, który mógłby być spożytkowany na development.

Czy Product Owner ma prawo umieścić w ostatniej chwili na początku Backlogu nowy, duży element, na którego pielęgnację (doprecyzowanie i ewentualny podział) nie będzie czasu przed Planowaniem Sprintu? Nie powinno zdarzać się często, ale jest możliwe. Zespół przyzwyczajony do pracy z elementami, które nie są superprecyzyjnie zdefiniowane, potrafi sobie w tej sytuacji poradzić – to dodatkowa korzyść z przeprowadzania pielęgnacji Backlogu w sposób minimalny i jednocześnie wystarczający. Natomiast Zespół, który używa pielęgnacji Backlogu Produktu do poprzedzenia realizacji każdego elementu wyczerpującą analizą, bez której nie jest w stanie zaplanować prac, będzie miał w tej sytuacji ogromny kłopot.

Uczestnicy

Forma, w jakiej pielęgnacja Backlogu Produktu się odbywa, zależy od ustaleń między członkami Zespołu Scrum. Nie decyduje o niej jednostkowo Product Owner, nie mogą jej narzucić Developerzy ani tym bardziej Scrum Master.

Zazwyczaj są to spotkania, pomiędzy którymi odbywają się dodatkowo jakieś analizy, dyskusje z ekspertami lub testy. Scrum Guide nie określa, jak i kiedy spotkania te organizować, ani czy w ogóle je robić – każdy Zespół ustala to indywidualnie. Nie ma więc zdefiniowanej listy uczestników – tak długo, jak osiągany jest cel pielęgnacji i nie cierpi na tym przejrzystość oraz empiryzm, tak długo dowolne rozwiązanie jest akceptowalne.

Oczywistymi uczestnikami pielęgnacji – jako procesu – są Developerzy oraz Product Owner. Przy czym Developerzy zazwyczaj poświęcają na to jedynie niewielką część czasu, jakim dysponują w Sprincie, natomiast Product Owner może 100% swojego czasu poświęcić na pielęgnację. Tym bardziej że wszystko, co robi, wykonując swoje obowiązki, ma na celu doprowadzenie Backlogu do stanu pozwalającego w kolejnym Sprincie uzyskać maksimum wartości.

Uwaga: istnieje mit, że Developerzy nie mogą wykorzystać na pielęgnacje więcej niż 10% czasu w Sprincie, ale to bzdura wynikająca z niezrozumienia zapisu w Scrum Guide. Nie jest to żaden limit, a jedynie rekomendacja, z której zresztą twórcy metody ostatecznie i tak się wycofali.

Poza Developerami i Product Ownerem najczęściej w pielęgnacji Backlogu Produktu uczestniczą eksperci, którymi mogą być interesariusze (wyjaśniający, czego potrzebują) albo eksperci techniczni (pomagający zrozumieć, co jest możliwe do zrealizowania). O tym, jakich ekspertów i kiedy należy zaprosić, decyduje – co oczywiste – cały Zespół. Ważne, by eksperci tacy służyli radą i dzielili się wiedzą, a nie instruowali Developerów lub Product Ownera, co i jak ma być zrobione.

Rola Scrum Mastera w tym procesie związana jest z zapewnieniem, że pielęgnacja następuje (jako proces, niekoniecznie jako spotkania) i nie zamienia się w ciężką analizę. Ciężką, czyli taką, która dąży do ustalenia wszystkiego w szczegółach, zanim rozpocznie się realizacja poszczególnych elementów Backlogu Produktu. Gdyby proces pielęgnacji zmutował w stronę fazy analizy znanej z podejścia projektowego, niewiele to będzie mieć wspólnego z działaniem empirycznym.

Z kronikarskiego obowiązku dodam, że czasami Scrum używany jest na siłę do rozwiązywania problemów, które nie leżą w domenie niestabilnej złożoności. Tam, gdzie da się skutecznie robić analizy i planować rzeczy ze sporym wyprzedzeniem, rozsądniej byłoby sięgnąć po inną metodę: klasyczną projektową, albo jakiś własny proces, najlepiej w połączeniu z Kanbanem. Natomiast jeśli tak nie jest, jeśli środowisko jest mocno zmienne i nieprzewidywalne, próba układania działań na wiele Sprintów do przodu skończy się kłopotami. Scrum Master ma obowiązek pomóc organizacji i Zespołowi w doborze metody do charakteru rozwiązywanych problemów.

Sposób realizacji

Najczęściej pielęgnacja Backlogu Produktu to spotkanie, w którego czasie Developerzy omawiają z Product Ownerem elementy Backlogu. Nie jest dobrym pomysłem robienie jednego takiego spotkania w ramach Sprintu, bo albo będzie ono długotrwałe i mało efektywne, albo braknie czasu na dyskusję i pielęgnacja rozminie się z celem, dla którego jest prowadzona.

Dobrym pomysłem jest ustalenie kilku krótszych sesji pielęgnacji, na przykład godzinnych. Zaplanowanie ich z góry w kalendarzu ułatwi przeprowadzenie spotkań, a jeśli nie będzie potrzeby, by się spotkać, niektóre z tych sesji można po prostu odwołać. Warto też ułożyć je tak, by dawały przestrzeń do zrobienia czegoś (analiz, testów, rozmów z ekspertami itd.) pomiędzy sesjami.

Koniecznie trzeba zadbać o strukturę sesji, które nie powinny zamieniać się w bezproduktywną dyskusję. Jeśli planujemy sesje godzinne, przyjmijmy zasadę, że o jednym wymaganiu rozmawiamy maksymalnie np. przez kwadrans albo przez dwadzieścia minut. Ten timebox doda dynamiki samemu spotkaniu, pozwalając omówić więcej niż jedno wymaganie na każdej sesji.

Jeśli ustalony czas kończy się, a dyskusja o jakimś elemencie Backlogu wciąż trwa, uczestnicy decydują, czy wykorzystać kolejny timebox na jej kontynuowanie. Mogą też zaparkować rozmowę do kolejnego spotkania i ustalić, kto i jakie działania wykona pomiędzy sesjami, aby uzyskać więcej informacji, rozstrzygnąć wątpliwości albo choćby zaprosić eksperta.

Taki model postępowania spowoduje, że większość elementów Backlogu omawiana będzie na więcej niż jednej sesji pielęgnacji. Na początku wystarczy być może jedynie zrozumieć, o co chodzi w wymaganiu. Potem niezbędna może okazać się dekompozycja na kilka mniejszych elementów. Gdzieś po drodze ustalone zostaną kryteria akceptacyjne (jeśli Zespół stosuje tę praktykę opcjonalną w Scrumie). Powolne doprecyzowanie wymagań (pielęgnacja – stąd nazwa procesu) rozłoży się w czasie na kilka sesji, pomagając w utrzymaniu poziomu szczegółowości analizy i planowania na poziomie wystarczającym i jednocześnie minimalnym.

Taki sposób pielęgnacji spowoduje też, że nie ograniczy się ona do spotkań i nie będzie robiona punktowo w jednym momencie Sprintu. Poza sesjami również wykonywane będą niezbędne działania, które napędzać mają dyskusję w czasie spotkań. Takiego efektu nie da się uzyskać, jeśli w Sprincie odbywa się jedna, kilkugodzinna narada, z której ludzie odpadają intelektualnie po pierwszych kilkudziesięciu minutach.

Pobierz opis schematu pielęgnacji w formacie PDF

Działania w ramach pielęgnacji

Na koniec przykładowa lista czynności, które mogą być wykonywane w ramach pielęgnacji, w zależności od potrzeb i aktualnego stanu elementów Backlogu Produktu.

• Omówienie elementów – w szczególności ustalenie, co jest celem i wartością, które pozwoli osiągnąć ich zrealizowanie.
• Oszacowanie wielkości (niekoniecznie rozumianej jako czas realizacji) – pozwoli to na lepsze zrozumienie elementu, umożliwi też Product Ownerowi prognozowanie potencjalnych terminów realizacji oraz jej kosztów.
• Dekompozycja elementów, jeśli są one zbyt duże, aby dało się zrealizować je w Sprintach.
• Ustalenie kryteriów akceptacji – to opcjonalna praktyka, w ramach której definiuje się warunki i cechy, jakie spełnić powinno akceptowalne rozwiązanie problemu biznesowego (uwaga: to nie to samo, co Definicja Ukończenia, która w Scrumie nie jest opcjonalna i łączy się z jakością strukturalną – tym, jak produkt jest zrobiony – a nie jakością funkcjonalną).
• Dyskusja o zależnościach – mogą one wpłynąć na kolejność elementu w Backlogu.
• Omówienie strategii realizacji, bo z niej wynikać mogą zależności, a na pewno będzie ona miała wpływ na pracochłonność – niemniej należy ograniczyć się do sporządzenia zarysu planu realizacji i podjęcia kluczowych decyzji architektonicznych.

Nie jest to oczywiście lista kompletna. W ramach pielęgnacji Product Owner lub Developerzy często przeprowadzają szereg innych czynności. Mogą to być wszelkiego rodzaju warsztaty z interesariuszami, służące ustaleniu, co jest wartością albo jak tę wartość uzyskać – na przykład User Story Mapping. Może to być też spike developerski, pozwalający na uzyskanie lepszego zrozumienia, co jest technicznie możliwe w produkcie.

Czego nie należy robić w ramach pielęgnacji? Poniżej prezentuję kilka działań, które bywają podejmowane przez niektóre Zespoły, a niekoniecznie przynoszą wartość lub wręcz szkodzą.

• Planowanie kolejnych Sprintów z wyprzedzeniem tak, aby Planowanie Sprintu w nich było formalnością i można było „od razu zabrać się do roboty”.
• Dekompozycja elementów na zadania developerskie lub budowanie detalicznych planów realizacji.
• Przypisywanie konkretnych elementów do określonych osób lub wręcz definiowania kto i co zrobić powinien w czasie implementacji.
• Tworzenie detalicznych analiz i specyfikacji rozwiązań z założeniem, że mają one zostać zrealizowane dokładnie tak, jak opisują owe analizy i plany.
• Dekompozycja elementów na „techniczne etapy realizacji”, a nie na wartościowe, mniejsze elementy – co uniemożliwi uzyskanie jakiejkolwiek wartości, zanim nie zrealizuje się wszystkiego.
• Układanie Backlogu „pod zależności” w sposób pozbawiający Product Ownera jakiejkolwiek swobody w określaniu kolejności elementów (zamiast tego należy szukać sposobu na wyeliminowanie lub ograniczenie zależności).
• „Przygotowywanie” wstępnie działającego rozwiązania, żeby „było szybciej w przyszłości” – co de facto oznaczałoby rozpoczęcie realizacji, zanim jeszcze wymaganie zostanie podjęte do jakiegokolwiek Sprintu.
• Budowanie „na brudno” prototypów po to, żeby potem „wiedzieć na pewno”, jak zbudować docelowe rozwiązanie – co prowadziłoby do realizowania każdego elementu dwukrotnie.

Odpowiedzialność za nauczenie Developerów i Product Ownera, po co jest pielęgnacja i jak ją robić, spoczywa, rzecz jasna, na Scrum Masterze.

Ciąg dalszy…

Zapoznaj się również z serią artykułów opisujących błędy, jakie Zespoły najczęściej popełniają w czasie pielęgnacji Backlogu Produktu. Wyjaśniam w nich, dlaczego nie warto cieszyć się z „krótkiego i sprawnego Planowania Sprintu”, które bywa wynikiem nadmiernej pielęgnacji Backlogu Produktu oraz jak źle robiona pielęgnacja może utrwalić lub wręcz wzmocnić silosy kompetencyjne w Zespole. Pierwszy z serii artykułów znajdziesz tutaj.