Backlog Grooming

Współtwórca Scruma, Ken Schwaber zaleca, aby 5% czasu sprintu przeznaczać na „Backlog Grooming”. Z moich doświadczeń
i rozmów o Agile z zespołami w FP wyłania się pożytek z takiej akcji.

Backlog jest prostą listą „zaległości projektowych”, czyli rzeczy do zrobienia w projekcie. Jest tworzony na początku projektu
– dostaje wtedy maksymalną liczbę „rzeczy do zrobienia”, jakie uda się wymyślić. Następnie backlog żyje – każda nowa rzecz, która wpadnie do głowy, trafia do backloga. Rzeczy, które przestały mieć sens, są z niego usuwane i tak dalej. Aby backlog był skuteczny każda pozycja na nim musi być oszacowana, a sama lista musi być posortowana priorytetowo. Elementy najwyżej umieszczone są planowane na najbliższą przyszłość, elementy niżej – na dalszy okres. Zgodnie z ideą „planning horizon”, elementy najwyżej powinny być niezbyt złożone (czyli powinny być możliwie mocno rozbite), jasne, z określonymi kryteriami akceptacyjnymi. Elementy niższe mogą być bardziej rozmyte i większe. Jakie problemy związane z backlogiem zauważyłem u siebie i w paru innych projektach? Więc:

• Zespół nie wie, co jest w backlogu. To jest narzędzie Product Ownera.
• Zespołu nie obchodzi, co jest w backlogu. Jakaś tam lista, będziemy to kiedyś robić, ktoś nam powie co robić.
• Elementy w backlogu są nieoszacowane – Product Owner nie wie jak je priorytetyzować.
• Elementy w backlogu planowane na najbliższą przyszłość są zbyt duże, źle zdefiniowane, niejasne dla Product Ownera (PO).
• PO też nie zastanawia się nad elementami z backloga, po prostu je tam wrzuca.
• Backlog nie jest narzędziem do długofalowego planowania, projekt toczy się „jak się potoczy, panie kierowniku”.
• Backlog nie jest wykorzystywany do analizy technicznej i projektowania/designu.

Jak widać – problemów jest dość sporo, niektóre są ważne. Backlog jest ważny. Bardzo ważny. Prawidłowe wykorzystanie tej prostej niby listy daje naprawdę dużo korzyści. Gdybym miał podać najważniejszą korzyść dobrego backloga, to powiedziałbym,
że jest to aspekt prawidłowo realizowanego planowania w Agile – planowanie rozciągnięte w czasie i cały czas dostosowujące się do aktualnej sytuacji, coraz dokładniejsze.

Zły backlog i złe procesy okołobacklogowe objawiają się także bardzo często podczas spotkań planujących sprint. Ręka do góry kto doświadczył zbyt długiego, nudnego, nieproduktywnego, spotkania planującego (podnoszę rękę). Ile razy się zdarza, że spotkanie ciągnie się w nieskończoność, ludzie nie wiedzą co robić, Product Owner nagle uświadamia sobie, że ma 20 pytań, które musi przemyśleć, albo z kimś pogadać? Spotkanie nie kończy się realizacją celów – jasno zdefiniowaną i zaplanowaną robotą na właśnie rozpoczynający się sprint.

Czym zatem jest „Backlog Grooming”? 

Jest to nieformalne spotkanie organizowane podczas aktualnie trwającego sprintu, najlepiej robione na 3 dni (lub więcej) przed spotkaniem planującym kolejny sprint.
Na spotkaniu obecni powinni być: zespół, Product Owner, Scrum Master. Niezalecana jest obecność innych osób,
np. stakeholderów czy innych ciekawskich.

Co się robi?

• Sprawuje się czułą opiekę nad backlogiem i jego obsługę – well, thank you, cpt. Obvious.
• Zespół szacuje wszystkie nowe elementy.
• Wszyscy przeglądają elementy, usuwają nieaktualne, doprecyzowują niejasności
• Jest robiona wstępna priorytetyzacja (PO, słuchając rad zespołu).
• Wspólne zrozumienie elementów.
• Rozbicie epiców na konkretne stories (lub jeśli nie ma stories to po prostu rozbicie kolosów na mniejsze elementy). Skupiamy się na tych planowanych na najbliższą przyszłość.
• Kwestionowanie i zadawanie pytań. Product Owner odpowiada, albo zapisuje sobie do wyjaśnienia.

Co nam to daje?

• Zespół zaczyna czuć się odpowiedzialny za wymagania, bo aktywnie uczestniczy w ich „groomingu”. Przykład negatywny
  – to gdy zespół na spotkaniu planującym pierwszy raz widzi wycinek góry backloga i dostaje „zadania” od Product Ownera.
• Planowanie na kilka najbliższych iteracji – można lepiej coś zaprojektować, głównie chodzi o aspekty techniczne (devowie to uwielbiają).
• Więcej wiedzy przed spotkaniem planującym – ten miniplan siedzi w głowie i można wstępnie już obmyśleć jak to podzielić na sub-taski techniczne, jak jeszcze lepiej oszacować.
• Lepsza perspektywa na przyszły research.
• Product Owner będzie zdecydowanie lepiej przygotowany na spotkanie planujące.
• Product Owner, dostając serię pytań, może podjąć jakieś działania korygujące.
• Zaczynają się tworzyć kryteria akceptacyjne dla planowanych tasków. A to oznacza, że można zacząć tworzyć testy akceptacyjne/funkcjonalne, czyli robić do bólu poprawne BDD. Idealny przykład – to posiadanie testów z kryteriami akceptacji dla zaplanowanych na sprint tasków w ten sam dzień, w którym jest spotkanie planujące. Wtedy idealnie działa BDD i w efekcie TDD.
• Spotkanie planujące jest efektywne, konkretne.

Potencjalne wady?

Odciągnięcie zespołu od aktualnie realizowanych zadań, konieczność wyjścia z „zone”, utrata produktywności. Wada ta jest traktowana dosyć marginalnie w świecie doświadczonych wymiataczy. Twierdzą oni, że taka odskocznia w połowie iteracji może wręcz być dobra dla zespołu. Pozwala mózgom zostawić na chwilę aktualne problemy, R-mode w tym czasie asynchronicznie rozwala te problemy, a zespół kreatywnie pielęgnuje sobie backlog i ustawia wizję najbliższej przyszłości. Do mnie to przemawia.

Ogólnie jestem jak najbardziej za Backlog Groomingiem. Nawet jeśli Product Owner jest kiepski lub wręcz w ogóle go nie ma, to i tak widzę sporo zalet w takim spotkaniu zespołu i omawianiu przyszłych tasków. Backlog musi być żywy i uporządkowany, bo tak samo jak kod, z czasem sobie gnije. Nie do końca zgadzam się z tym 5% czasu. Wydaje mi się, że można celować w mniejsze wartości.
1-2 h na 2 tygodniowy sprint powinno w zupełności wystarczyć, choć oczywiście wszystko jest zależne od kontekstu.

Jeśli jeszcze nie robicie Backlog Groomingu, to polecam na kolejnym retro chwilę o tym pogadać i zastanowić się czy nie chcielibyście spróbować i zobaczyć czy to ma sens.
Ja na pewno będę zbierał takie doświadczenia i przekazywał dalej.