Ten post jest częścią cyklu Pierwsze Dni Scrum.
Wczoraj rozmawialiśmy o tym, jak ważną rolę w Scrum pełni Właściciel Produktu i jego główne narzędzie komunikacji, jakim jest Backlog Produktu. Dzisiaj przyjrzymy się temu, jak powinien wyglądać Backlog, żeby dobrze pełnił swą rolę.
Do czego właściwie służy Backlog?
Backlog Produktu jest narzędziem planowania. Planowanie to ma dwa główne cele:
- pomagać zespołowi jak najszybciej dostarczać największą możliwą wartość,
- ułatwić organizację pracy i śledzenie jej postępów.
Jakie są cechy dobrego backlogu?
Aby skutecznie realizować wyżej wymienione cele Backlog powinien być:
- Zrozumiały dla PO, zespołu i odbiorców – tylko wtedy może stymulować i wspierać rozmowy, które są niezbędne do określenia gdzie leży wartość i jak zespół może ją dostarczyć uwzględniając ograniczenia osobowe, techniczne i organizacyjne.
- Uporządkowany z uwzlędnieniem wartości, pracochłonności i ryzyka, w taki sposób, żeby jego sukcesywne realizowanie przynosiło organizacji największe możliwe korzyści. Nie istnieje jednoznaczny algorytm pozwalający pogodzić wszystkie te czynniki: odpowiednie ich wyważenie powinno wyłaniać się z komunikacji między PO, zespołem i odbiorcami.
- Żyjący – Backlog powinien ewoluować wraz z wzrastającą wiedzą wszystkich zainteresowanych. Wymagania “na teraz” powinny być GOTOWE (patrz niżej), a dalsze plany mogą być jedynie naszkicowane. Powinniśmy unikać przeinwestowania w szczegółowe rozpisanie backlogu na wiele miesięcy do przodu, bo praca ta zostanie zmarnowana przez nieuniknione zmiany.
Nie tylko historyjki
W zwinnych zespołach elementy backlogu najczęściej mają formę historyjek użytkownika (którymi zajmiemy się jutro). Nie jest to jednak obowiązek. Elementy backlogu mogą mieć też inne formy:
- Hasłowe określenie tematu historyjki, o ile jest zrozumiałe dla wszystkich zainteresowanych.
- Bardziej szczegółowy opis funkcjonalności np. w formie pełnych przypadków użytkownika (use case) lub wręcz siatek poszczególnych widoków. Takie podejście ma swoje wady, ale czasem jest właściwym rozwiązaniem.
- Defekt odkryty po zakończeniu sprintu (warto zainwestować w jakość wewnątrz sprintu, by było ich jak najmniej).
- Eksperyment techniczny nie będący realizacją konkretnej funkcjonalności, ale pozwalający odpowiedzieć na ważne pytania i podjąć lepsze decyzje co do dalszego rozwoju produktu.
-
Cel biznesowy bez określenia sposobu jego realizacj. W takim przypadku warto określić:
- wartość jaka nas interesuje np. łatwość użycia, responsywność lub konwersja,
- miarę, która pozwoli nam zmierzyć tą wartość np. % wykonania zadania z sukcesem w testach z 20 użytkownikami, czas oczekiwania na otwarcie danej strony lub konwersja (w tym przypadku wartość jest jednocześnie miarą).
- punkty odniesienia np. w przypadku responsywności: zastępowany system: 1 min, obecna wersja nowego systemu: 30 sek, główny konkurent: 15 sek, nasz cel: 10 sek.
Ta ostatnia metoda zostawia najwięcej swobody zespołowi, co pozwala najskuteczniej wykorzystać pełen zakres kompetencji i kreatywności jego członków, lecz jest też najbardziej wymagająca z punktu widzenia psychologicznego i organizacyjnego.
Co to znaczy, że element backlogu jest GOTOWY?
Elementy backlogu zakończone przez zespół w danym sprincie muszą być zrobione “na gotowo” (czyli spełniać Definicję Ukończenia, ang. Definition of Done). W przeciwnym wypadku Właściciel Produktu nie może ich zaakceptować i nieskończone elementy smutno wracają do Backlogu by być zrepriorytetyzowane (i być może porzucone). Tak samo historyjki przedstawiane przez PO do realizacji powinny być GOTOWE do realizacji.
Co to znaczy gotowe? Dobrze opisuje ten problem Roman Pichler w artykule “The Definition of READY”. Według Romana najważniejsze jest by GOTOWE elementy backlogu były:
- zrozumiałe i jednoznaczne (clear) – wszyscy zainteresowani muszą rozumieć o co chodzi,
- testowalne – musi się dać jednoznacznie odpowiedzić na pytanie czy dany element działa poprawnie,
- realistyczne – muszą być możliwe do zrealizowania przez zespół w jeden sprint, uwzgledniając też przewidywane zaburzenia w pracy (urlopy, święta, wydarzenia firmowe, nagłe ataki zimy, itd.).
To dobre kryteria, jednak zawsze powinny być przez Was uzupełnione i dostosowane do Waszych potrzeb. Wynikająca z tych ustaleń Definition of Ready powinien być zapisany w powszechnie dostępnym miejscu tuż obok Definition of Done, a zespół powinien mieć prawo (i obowiązek) by nie przyjmować do realizacji historyjek, które nie są GOTOWE.
Kiedy w Scrum zajmujemy się Backlogiem?
Z powyższych rozważań wynika, że wytworzenie i utrzymanie dobrego backlogu może być bardzo pracochłonne. Wysiłek ten jednak zwraca się z nawiązką już po kilku sprintach i dlatego warto zarezerwować w procesie odpowiednio dużo czasu na pracę nad backlogiem. W Scrum przyjmuje to formę następujących wydarzeń:
- Planowanie Wydania – obejmuje wzmożoną pracę PO, który wspólnie z zespołem i w porozumieniu z odbiorcami musi przygotować listę rzeczy do zrobienia wykraczającą tak daleko w przyszłość, jak jest to niezbędne (zwykle kilka sprintów lub kwartał) i doprowadzić najbliższe zadania do stanu GOTOWOŚCI.
- Planowanie Sprintu – to ostatnia szansa na dopracowanie najpilniejszych historyjek. Obejmuje szczegółowe omówienie ich znaczenia oraz proponowanego rozwiązania oraz przyjęcie danego elementu przez zespół do realizacji.
- Backlog Grooming (pielęgnacja lub “czesanie” backlogu) – to worek na mniej obciążające prace równomiernie rozprowadzone między pozostałe prace. W ramach pielęgnacji backlogu PO sam ulepsza, przepisuje i zmienia kolejność elementów backlogu, deleguje część tych zadań na zespół oraz potwierdza trafność i aktualność nadchodzących zadań z odbiorcami systemu. Dobrą praktyką jest zarezerwowanie około 10% czasu zespołu na pielęgnację backlogu. Jeśli zespół poświęca na to mniej czasu to backlog będzie zbyt oderwany od realiów ich pracy, a jeśli dużo więcej to zaburzy realizację bieżacych zadań.
Pytania dla Was:
Czy macie jedno miejsce, w którym zebrane są wszystkie źródła wymagań dla pracy zespołu?- Czy Wasz backlog jest zrozumiały dla wszystkich zainteresowanych?
- Czy zawsze na szczycie listy znajdują się rzeczy najważniejsze?
- Czy na bieżąco pielęgnujecie backlog uwzględniając najświeższe informacji?
- Czy wymagania na szczycie backlogu są GOTOWE?
- Kiedy Wasz backlog działa najlepiej?
- Co moglibyście zrobić, żeby częściej działał w ten sposób?
Co dalej?
Jutro przyjrzymy się bliżej historyjkom użytkownika, w czwartek omówimy Planning Poker – popularną metodę wymiany informacji ukrytą pod postacią metody szacowania, a w piątek zajmiemy się długofalowym planowaniem.
