W tej odsłonie bloga chciałbym zająć się tematem backlog-u a konkretnie elementów backlog-u. Jest wiele opracowań mówiących o elementach backlog-u ale trochę gorzej z praktycznymi poradami jak sobie radzić i wykrywać problemy. Pominę tu oczywiste aspekty opisane w Scrum Guide jak to, że elementy backlog-u powinny być czytelne, ułożone w celu maksymalizacji wartości itp. Również problemem w pisaniu ogólnych wskazówek jest fakt, że każdy produkt, zespół i właściciel produktu jest inny więc stworzenie ogólnego przewodnika jest niemożliwe. Więc chciałem tylko wrzucić kilka porad z mojej praktyki co jest sygnałem, że backlog można byłoby poprawić.

Zacznijmy od tego, że cały sekret tkwi w ziarnistości elementów backlog-u. Zacytuję tu za jednym z moich ulubionych filmów „Helikopter w ogniu”: nie za grubo i nie za drobno. Wiem, śmiejecie się, bo to znów oczywiste, powiedz nam coś, czego nie wiemy. Więc do rzeczy:

Co jest symptomem, że elementy backlog-u są zbyt drobno „zmielone”:

• Takim najbardziej oczywistym wskaźnikiem jest fakt, że przypominają konkretne zadania do wykonania. Na refinement zespół zaczyna się nudzić, elementy są tylko omawiane (bez większej dyskusji – raczej tylko kilka pytań) i estymowane, po pewnym czasie pojawia się coraz większa niechęć do przychodzenia na refinement
• Drobno zmielone elementy backlog-u na dalszą przyszłość są wskazówką, że zaczynamy iść w stronę kaskadowego modelu ze Scrum w środku
• Mniej oczywistą wskazówką są krążące po zespole stwierdzenia typu „gdybyśmy wiedzieli wcześniej jak to jest używane to inaczej by to było zrobione”. Tu nie zawsze trzeba reagować, bo może być to efektem zmian w backlog-u, ale jeśli w kolejnych sprintach takie opinie się pojawią a elementy w backlog-a były już znane wcześniej to jest to wyraźny sygnał
• Inną nieoczywistą wskazówką jest konieczność zmiany modelu danych/elementów oprogramowania w kolejnych sprintach przez nowe wymagania – czy na pewno dobrze podzieliliśmy wymaganie jeśli kolejne „klocki” wywracają implementację?
• Kolejnym sygnałem jest informacja zwrotna z przeglądu sprintu – jeśli z drobnych wymagań złożona została większa funkcjonalność i interesariusze zaczynają narzekać i mówić o niskiej użyteczności to może to być sygnał, że dekompozycja wymagań była niewłaściwa
• No i kolejny sygnał również z zespołu lub interesariuszy – jeśli po oddaniu większego kawałka funkcjonalności widać, że implementacja jest przerysowana (powstała armata do zabicia muchy) i trudna w użyciu

Co może świadczyć o zbyt „grubym” podejściu do wymagań:

• Realizacja przestaje się mieścić w sprincie.
• Podczas prezentacji właścicielowi produktu gotowych części pojawia się dyskusja i duża ilość zmian – to niekoniecznie świadczy o zbyt dużej „grubości”, może być po prostu sygnałem o jeszcze niedostatecznym zgraniu lub zbyt krótkim refinement
• Zespół nie jest w stanie stworzyć sobie zadań na iterację na podstawie wymagania pomimo dobrze zrobionego refinementu – być może zespół jeszcze nie jest doświadczony na tyle, żeby przejść na taki poziom lub faktycznie wymagania są zbyt ogólnie sformułowane
• Bardzo intensywny kontakt z właścicielem produktu, dużo dopytywania a efekt końcowy odbiega od oczekiwań – to też sygnał, że może trzeba bardziej dekomponować

Po samym uruchomieniu Scrum nie warto poświęcać zbyt dużo czasu na dążenie do ideału – i tak nie wiemy jak on wygląda. Inspekcja i adaptacja załatwi temat w krótkim czasie. Natomiast warto zwrócić uwagę, aby właściciel produktu nie zaplanował zbyt szczegółowo backlog-u – z doświadczenia wiem, że trudno później dokonywać zmian, jeśli od początku powstał szczegółowy plan. Lepiej zacząć od „grubszych” elementów i dopracować sobie dekompozycję podczas kolejnych refinementów.

Chciałbym zaznaczyć, że w miarę nabierania doświadczenia przez zespół i właściciela produktu warto zmieniać ziarnistość na coraz grubszą. To w większym stopniu daje poczucie współuczestniczenia przez cały zespół w tworzeniu produktu i jest jednym z głównych czynników motywujących.

I jeszcze na koniec – dekompozycja wymagań przez cały zespół Scrum jest w jednym z podstawowych wymagań jeśli dążymy do uzyskania pełnych efektów Agile. Jeśli tylko właściciel produktu dekomponuje wymagania to świadczy to o poważniejszym problemie.