Blog

Cel pielęgnacji

Pielęgnacja ma doprowadzić backlog produktu do stanu, dzięki któremu zespół scrumowy potrafi zaplanować najbliższy sprint. Efektem skutecznej pielęgnacji jest więc dobre zrozumienie przez cały zespół scrumowy jakie elementy znajdują się na szczycie backlogu i dlaczego taka, a nie inna jest ich kolejność.

Aby dało się zaplanować sprint, elementy w górnej części backlogu 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 zbudować plan ich realizacji.

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.

W czasie pielęgnacji powinno się zwracać uwagę na zależności, które mogą uniemożliwić realizację niektórych wymagań. To pozwala Product Ownerowi uporządkować backlog tak, by zależności te wyeliminować albo przynajmniej ograniczyć. Ale znów trzeba uważać, by nie wpaść do studni niekończących się analiz w złudnym dążeniu do uzyskania pewności, że na pewno coś da się zrobić.

Dyskusja o detalach implementacyjnych i konkretnych działaniach odbywać się powinna dopiero na planowaniu sprintu. To pozwala uniknąć wkładania wysiłku w wymagania, które Product Owner może w dowolnym momencie usunąć z backlogu. Budowany z dużym wyprzedzeniem plan realizacji najpewniej szybko się zdezaktualizuje, a do tego będzie „kotwiczył” myślenie developerów o możliwych rozwiązaniach. To utrudni im wybór optymalnego sposobu realizacji wymagania w tym sprincie, w którym będzie ono implementowane.

W pielęgnacji nie chodzi również o to, by uzyskać odpowiedzi na wszystkie pytania i w szczegółach omówić sposób realizacji elementów backlogu. Takie detale ustalone zostaną dopiero w czasie planowania sprintu, a uzyskiwanie odpowiedzi na otwarte pytania może stanowić jeden z etapów realizacji. To pozwala uniknąć sytuacji, w której kosztem czasu bieżącego sprintu realizowane są długotrwałe i szczegółowe analizy tego, co może, ale niekoniecznie musi być robione w sprintach kolejnych.

Product Owner wciąż ma prawo umieścić w ostatniej chwili na szczycie 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 wymaganiami, 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 w ramach pielęgnacji backlogu produktu poprzedza realizację każdego wymagania wyczerpującą analizą, będzie miał w tej sytuacji ogromny kłopot.

Uczestnicy

Forma, w jakiej pielęgnacja backlogu jest realizowana, zależy od ustaleń między Product Ownerem, a zespołem developerskim. 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ół scrumowy 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 nie poświęcają na to więcej niż 10% czasu w sprincie (mogą więcej, jeśli jest ku temu dobry powód). Natomiast Product Owner może 100% swojego czasu poświęcić na pielęgnację, ponieważ wszystko, co robi wykonując swoje obowiązki, ma na celu doprowadzenie backlogu do stanu pozwalającego w kolejnym sprincie uzyskać maksimum wartości.

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ół scrumowy. 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 jest robiona i nie zamienia się w ciężką analizę. Ciężką, czyli taką, która dąży do ustalenia wszystkiego z góry i przewidzenia (zaplanowania) wszystkiego, 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 – jeśli chcemy wciąż działać zwinnie – metodę Kanban. 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 to spotkanie, w czasie którego developerzy omawiają z Product Ownerem elementy backlogu produktu. Nie jest dobrym pomysłem robienie jednego takiego spotkania w czasie 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ę samej sesji, które nie powinny zamieniać się w bezproduktywną dyskusję. Jeśli planujemy sesje godzinne, przyjmijmy zasadę, że o jednym wymaganiu rozmawiamy maksymalnie 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 elementów. Gdzieś po drodze ustalone zostaną kryteria akceptacyjne (jeśli zespół stosuję tę opcjonalną praktykę). Powolne doszczegółowienie wymagań (pielęgnacja – stąd nazwa procesu) rozłoży się w czasie na kilka sesji, pomagając w utrzymaniu 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 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 wymagań – w szczególności ustalenie, co jest celem biznesowym i wartością, którą pozwoli osiągnąć zrealizowanie wymagania.
• Oszacowanie wielkości (niekoniecznie rozumianej jako czas realizacji) – pozwoli to na lepsze zrozumienie wymagania, umożliwi też Product Ownerowi prognozowanie potencjalnych terminów realizacji oraz jej kosztów.
• Dekompozycja wymagań – 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ść – tym niemniej należy ograniczyć się do sporządzenia co najwyżej zarysu planu realizacji i podjęcia kluczowych decyzji architektonicznych.

Nie jest to oczywiście lista kompletna. W ramach pielęgnacji Product Owner lub zespół developerski może przeprowadzać szereg innych czynności. Mogą to być wszelkiego rodzaju warsztaty z interesariuszami, służące ustaleniu, co jest wartością – przykładem może być sesja Story Mappingu. Może to być też spike zespołu developerskiego, 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 było formalnością i można było „od razu zabrać się do roboty”.
• Dekompozycja wymagań na zadania lub budowanie detalicznych planów realizacji.
• Przypisywanie konkretnych wymagań 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 wymagań na „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 jeszcze nim 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 wykonywania każdego wymagania dwukrotnie.

Odpowiedzialność za nauczenie zespołu developerskiego i Product Ownera po co jest pielęgnacja i jak ją robić, spoczywa, rzecz jasna, na Scrum Masterze.

A jak w ogóle przygotować się do pielęgnacji? O tym przeczytać można w artykule Jakuba Bażeli.

Ciąg dalszy nastąpi…

Już wkrótce ukaże się kolejny artykuł opisujący błędy jakie zespoły najczęściej popełniają w czasie pielęgnacji backlogu produktu. Wyjaśnię w nim dlaczego nie warto cieszyć się z „krótkiego i sprawnego planowania”, 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.