W 2005 roku Mike Cohn napisał na liście mailingowej Scrum coś, co z perspektywy czasu wygląda jak niewinne słowo rzucone w tłum. Użył terminu „backlog grooming” i nawet nie bardzo traktował tego jak propozycję formalnego procesu, raczej jak opis praktyki, którą i tak większość dobrych zespołów jakoś tam uprawiała. Kilkanaście lat później to samo słowo budzi na spotkaniach albo zbiorowe westchnienie, albo zbiorowe milczenie. Rzadko entuzjazm.
Żeby było jasne, co się właściwie kryje pod tym pojęciem: backlog grooming, przemianowany w Scrum Guide w 2013 roku na „Product Backlog Refinement”, to regularna sesja robocza, podczas której Product Owner razem z zespołem developerskim przegląda backlog produktu, porządkuje go, nadaje priorytety i rozkłada większe historyjki na mniejsze kawałki. Nie Sprint Planning, nie Daily, nie Retrospektywa. Osobne spotkanie, o własnej logice i własnych grzechach.
Skąd pochodzi ten dziwny termin
„Grooming” dosłownie oznacza pielęgnację, czesanie, układanie. W języku angielskim mówi się tak o kotach, psach i koniach przed wystawami. Że backlog też wymaga regularnego czesania, wpadł na to Cohn, a Roman Pichler rozwinął tę ideę w swojej książce „Agile Product Management with Scrum” z 2010 roku, poświęcając zarządzaniu backlogiem osobny rozdział. Potem przyszedł Scrum Guide w wersji z 2011 roku, który wspomniał o tej praktyce niemal mimochodem, a dwa lata później oficjalnie zmienił nazwę na „refinement”, bo słowo „grooming” nabrało w anglosaskim kręgu kulturowym nieciekawych konotacji. Polska branża IT w większości tego nie zauważyła i do dziś używa obu nazw wymiennie, co jest może jedynym dowodem na to, że komunikacja między polskim a angielskim środowiskiem Scruma wciąż kuleje.
Co się podczas tego spotkania naprawdę dzieje
Oficjalnie: zespół i Product Owner siadają raz lub dwa razy na sprint, przeglądają elementy backlogu, szacują złożoność przy użyciu technik takich jak Planning Poker, rozbijają zbyt duże historyjki (Mike Cohn nazywa je „epics” w „Agile Estimating and Planning”) i upewniają się, że to, co trafi do następnego Sprint Planning, jest gotowe do pracy. Scrum Guide nie narzuca konkretnej formy ani czasu trwania, sugeruje jedynie, że refinement nie powinien pochłaniać więcej niż 10% czasu zespołu w danym sprincie. Przy dwutygodniowym sprincie daje to mniej więcej cztery godziny.
Nieoficjalnie: wyobraźmy sobie zespół 8 deweloperów, Product Owner, który wrócił właśnie z tygodniowej konferencji, i backlog w Jirze z 200 otwartymi ticketami, z których 60 nie było tykane od roku. Ktoś pyta, czy historyjka „Integracja z systemem X” jest nadal aktualna. Cisza. Ktoś inny zagląda do niej i widzi opis sprzed 14 miesięcy, bez kryteriów akceptacji, przypisaną do osoby, która już nie pracuje w firmie. Product Owner mówi, że „to nadal ważne, ale może poczeka”. Godzina minęła, backlog ma 200 ticketów jak miał. Taka sesja raczej nie jest wyjątkiem. Trochę tak wygląda refinement w znacznej części zespołów scrumowych, które robiły transformację Scrum bez pełnego przygotowania organizacyjnego.
Dlaczego backlog tak szybko sypie się bez regularnej pielęgnacji
Backlog produktu to w pewnym sensie żywy dokument, a żywe dokumenty bez opieki zarastają. Kahneman w „Thinking, Fast and Slow” opisuje mechanizm, który można tu zastosować niemal jeden do jednego: ludzie mają tendencję do dodawania rzeczy do list znacznie łatwiej niż do ich usuwania, bo usuwanie wymaga świadomego wysiłku i poczucia straty. W praktyce oznacza to, że każdy pomysł, każde życzenie stakeholdera i każdy „może kiedyś to zrobimy” ląduje w backlogu i tam zostaje. Po sześciu miesiącach pracy lista rośnie szybciej niż zespół jest w stanie ją konsumować, a Product Owner przestaje panować nad tym, co w niej jest. Dobry backlog powinien być jak kolejka do kasy w dobrze zarządzanym supermarkecie, nie jak przechowalnia bagażu na dworcu.
O tym, jak bardzo backlog może żyć własnym życiem niezależnie od rzeczywistości projektu, pisaliśmy szerzej w artykule o tym, czym backlog bywa w firmach, a czym powinien być. Konkluzja jest tam raczej pesymistyczna.
Co odróżnia sesję, która działa, od sesji, która tylko zajmuje kalendarz
Refinement działa, gdy Product Owner przychodzi przygotowany, czyli zanim sesja się zacznie, sam przejrzał przynajmniej górę backlogu i wie, co chce omówić. Działa, gdy historyjki mają zdefiniowane kryteria akceptacji zanim trafią na spotkanie, bo bez nich szacowanie jest trochę jak wycenianie remontu bez oglądania mieszkania. Działa też, gdy zespół rozumie cel biznesowy stojący za każdą historyjką, nie tylko jej opis techniczny. Jeff Dalton w opracowaniu poświęconym backlog groomingowi zauważa, że kluczowy jest tu właśnie dialog między Product Ownerem a zespołem, a nie jednostronne przekazywanie wymagań.
Nie działa, gdy refinement sprowadza się do odczytywania tytułów ticketów i pytania „kto to ogarnie”. Nie działa, gdy backlog ma tyle elementów, że zespół nie jest w stanie objąć go wzrokiem. Nie działa, gdy Product Owner jest jedyną osobą, która wie, dlaczego cokolwiek jest w backlogu. Wtedy zamiast sesji pielęgnacji mamy audyt systemu, który nikt nie chciał przeprowadzić.
Pytanie, które warto sobie zadać po każdym refinemencie: czy Sprint Planning jutro będzie dzięki temu łatwiejszy? Jeśli odpowiedź brzmi „mniej więcej tak samo jak zwykle”, to coś poszło nie tak. Albo poszło tak samo jak zwykle, co w przypadku backlog groomingu często na jedno wychodzi. Więcej o tym, jak wygląda backlog produktu, gdy naprawdę pełni swoją funkcję, a gdy tylko zajmuje miejsce w narzędziu do zarządzania, znajdziesz w artykule o przykładach backlogi produktu z życia wziętych.
Źródła
- Schwaber K., Sutherland J., „Scrum Guide”, scrumguides.org, wydanie 2020 (wcześniejsze wersje: 2011, 2013, 2017).
- Pichler R., „Agile Product Management with Scrum”, Addison-Wesley, 2010.
- Cohn M., „Agile Estimating and Planning”, Prentice Hall, 2005.
- Kahneman D., „Thinking, Fast and Slow”, Farrar, Straus and Giroux, 2011.
- Dalton J., „Backlog Grooming”, w: „A Practitioner’s Guide to Scaled Agile Framework”, Apress, 2018.
- Agile Alliance, „Backlog Refinement”, glosariusz Agile Alliance, agilealliance.org.
Zdjęcie: Edgar Soto / Unsplash
