Backlog produktu to termin wywodzący się ze SCRUM i oznacza jedno miejsce w którym rejestrowana jest cała praca, która ma zostać wykonana, w celu dostarczenia produktu.
Czemu tak zawile? Czemu nie napisać, że backlog to zbiór wymagań dla produktu? Bo to nie tylko zbiór wymagań, ale zbiór wszystkich rzeczy, które potencjalnie mogą przynieść wartość dla użytkownika:
- wymagania funkcjonalne (np. user story, use case, designy,)
- wymagania niefunkcjonalne,
- bugi,
- change requests itd.
Wszystko co Product Owner i zespół uważają, że jest konieczne do dowiezienia wartości stakeholderom. Takie poszczególne elementy backlogu nazywamy Product Backlog Item (PBI).
Nie jest to jednak worek do którego Product Owner wrzuca (albo powinien wrzucać) wszystkie życzenia jakie pojawiają się ze strony stakeholderów. Pełnoprawny Product Owner częściej mówi “nie” niż “tak” 😉
W moim przekonaniu dobrze zarządzany backlog produktu obejmuje:
- PBIs, które spełniają Definition of Ready na 1-2 sprinty do przodu
- PBIs, które są w trakcie refinementy na kolejne 1-2 sprinty do przodu
- Całą resztę PBIs, które są w różnym stopniu zdefiniowania
Wszystkie te elementy są uszeregowane według istotności i przyjętych kryteriów priorytetyzacji.
Czym jest backlog management?
Backlog management obejmuje:
- dodawaniem i usuwaniem PBI do i z backlogu,
- priorytetyzację lub po prostu uszeregowanie elementów backlogu w kolejności ich realizacji,
- granularne przygotowanie i podział za dużych elementów na mniejsze,
- cykliczne review całego backlogu
Dodawanie wymagań
Dodawanie wymagań to, wydawałoby się, najprostsza z aktywności. Tworzymy notkę i już.
Nie idź tą drogą!
Oczywiście, jak chcesz coś na szybko dodać (np. podczas spotkania, żeby nie umknęło) to ok, ale nie zostawiajmy notek “gołych”.
Ja zarządzając backlogiem mam określone kryteria, które PBI musi spełniać.
Należą do nich m.in. status dojrzałości wymagania – a więc status w jakim znajduje się wymaganie. Mogą to być np.:
- “to be specified” – potrzebna jest analiza i wyspecyfikowanie zadania,
- “ready for refinement” – moja część specyfikacji jest już zrobiona, wymaganie może być przedyskutowane z zespołem,
- “design needed” – brakuje designów,
- “to be discussed with stakeholders” – z jakiegoś powodu należy porozmawiać ze stakeholderami. Może chodzić o doprecyzowanie wymagania, rozpatrzenie alternatywnego rozwiązania lub cokolwiek innego. Szczegóły zawsze zapisuję w treści notki.
Pilnuję też, żeby wymagania nie były wolnymi elektronami – muszą być powiązane z wymaganiami wyższego rzędu, żebym była pewna, że wspierają cel biznesowy.
Priorytetyzacja / uszeregowanie
Powoli odchodzi się od “priorytetyzowania” backlogu, na rzecz “uszeregowania”. Póki co moje odczucie jest takie, że nadal chodzi o to samo, tylko nazywamy to inaczej, żeby było łatwiej cały proces przeprowadzić. Tak czy inaczej jest to częścią zarządzania backlogiem. Więcej o priorytetyzowaniu możesz przeczytać tutaj.
Granularne przygotowanie i podział dużych elementów na małe
Elementy lepiej przygotowane do developmentu powinny znajdować się wyżej w backlogu niż te elementy, nad którymi jeszcze musimy popracować, dospecyfikować, albo np. rozbić.
Rozbijanie notek większych na mniejsze to część pracy Product Ownera, ale i całego zespołu.
Po co rozbijać wymagania?
Elementy w backlogu powinny być na tyle małe, żeby mógłby być dowiezione w czasie jednego sprintu, ale na tyle duże, żeby wnieść wartość w produkt.
Sprint to jest pewnego rodzaju umowa – umawiamy się na to, jaki przyrost wartości dostarczymy po określonym czasie. Jest to odpowiedzialność całego zespołu. Jeżeli więc mamy wątpliwości, czy jakieś wymaganie może być dowiezione w czasie sprintu, koniecznym jest podzielenie go na mniejsze części.
Temat dzielenia notek jest obszernym tematem, pewnie na niejeden artykuł, ale polecam zapoznać się ze schematem przygotowanym przez Richarda Lawrence’a.
Backlog Review
Ten ostatni punkt jest bardzo ważny, ale bardzo ciężki czasem do zrealizowania. Nigdzie nie jest powiedziane jak często Product Backlog Review powinien być prowadzony, ani jak dużo czasu ma się mu poświęcić. To zależy od produktu i wielkości backlogu.
Ja często przyjmuję sobie zestaw kryteriów, którymi kieruję się przy zarządzaniu backlogiem.
Na przykład:
- Elementy starsze niż X dni są z niego usuwane.
- Wymagania zgłoszone przez stakeholdera, który nie ma czas przez X dni na rozmowę o nich – również.
- Status dojrzałości wymagania jest identyfikowany konkretną labelką/tagiem
- W backlog nie mogą znajdować się “wolne elektrony” a więc elementy nie związane z innymi wymaganiami (biznesowymi, stakeholdehrów, rozwiązania)
itd.
Żeby maksymalnie ułatwić sobie egzekwowanie tych zasad, tworzę w Jira zestaw subskrypcji, które poinformują mnie, jeżeli jakiś PBI nie spełnia kryteriów. Mam również zaplanowane systematyczne sesje na refinement zarówno samodzielny jak i ze stakeholderami.
Podsumowanie
Nadrzędnym celem zarządzania backlogiem powinno być, żeby był on dla wszystkich przejrzysty i zrozumiały. Ma również jasno odpowiedzieć na pytanie “co robimy w następnej kolejności?” Bo jak pisze Tomek Wykowski:
“Źle zarządzany Backlog Produktu najczęściej oznacza, że skupiamy się na tym, co jest nam łatwiej zrobić, co wiemy, jak robić, co ważne dla najgłośniej krzyczącej osoby w firmie albo co będzie fajnie wyglądało w CV.”
