Rozmiar i kształt idealnego backlogu produktu

Jak długi powinien być backlog produktu? Jak powinien być zorganizowany? Czy istnieje na to uniwersalna reguła, czy jest to specyficzne dla danego produktu?

Cykl życia wymagania

By zrozumieć jak powinien być zorganizowany backlog, musimy przyjrzeć się co dzieje się z wymaganiami, gdy zmieniają się z luźnego pomysłu w działającą implementację.

Jest to wielokrokowy proces:

• Najpierw mamy ogólny pomysł: chcemy sprzedawać bilety lotnicze.
• Następnie dekomponujemy ten pomysł na paczkę zgrubnych funkcjonalności: klient musi być w stanie wyszukać lot, musimy zebrać dane osobowe klienta żeby zarezerwować lot, musimy obsłużyć różne formy płatności, musimy być w stanie przesłać klientowi bilet itd.
• W końcu dekomponujemy każdą funkcjonalność na niewielkie historyjki użytkownika: potrzebujemy formularz by zebrać dane osobowe, formularz powinien mieć walidację, powinniśmy wyświetlić jasne komunikaty błędów jeżeli dane są niepoprawne, po wysłaniu poprawnych danych klient powinien zostać zapytany o preferowaną formę płatności itd.

Oczywiście kroków może być więcej, zwłaszcza dla nowego produktu. Jednakże, możemy z grubsza wyróżnić 3 ogólne typy pozycji na backlogu produktu:

• projekty
• komponenty projektów
• szczegóły implementacji

3 poziomy podejmowania decyzji

3 typy pozycji (projekty, komponenty projektów, szczegóły implementacji) wymagają decyzji na różnym poziomie i podejmowanych przez różne osoby:

• Na poziomie projektu, PO wspierany przez kluczowych interesariuszy i management decyduje, które projekty powinny dostać “zielone światło” i w jakiej kolejności: Czy sprzedaż biletów lotniczych jest w ogóle warta inwestycji? Czy powinna zostać zaimplementowana wcześniej czy później niż sprzedaż rezerwacji hotelowych?
• Na poziomie komponentów projektu, PO wsperiany przez interesariuszy, ekspertów domenowych i zespół developerski decyduje, które funkcjonalności są dla projektu krytyczne i wygenerują największą wartość: Czy potrzebujemy wszystkich form płatności by sprzedawać bilety lotnicze? Czy możemy w pierwszej wersji zaimplementować wsparcie tylko dla jednej? Jeśli tak, która z nich będzie najlepszym kompromisem pomiędzy kosztem implementacji, kosztem operacyjnym i użytecznością?
• Na poziomie szczegółów implementacji, zespół developerski wspierany przez PO, ekspertów domenowych i interesariuszy decyduje jak najefektywniej zbudować daną funkcjonalność: Czy możemy zbierać dane użytkownika bez walidacji? Czy wystarczy, że zwalidujemy jedynie że pola nie są puste? Czy musimy wyświetlać szczegółowe komunikaty błędów czy wystarczy, że jedynie zaznaczymy niepoprawne pole na czerwono?

3 poziomy szczegółowości

Podejmowanie decyzji na różnych poziomach wiąże się z różnym poziomem szczegółowości opisów pozycji:

• Decyzje na poziomie projektu wymagają informacji strategicznych: Jak duży jest rynek biletów lotniczych? Jak bardzo jest konkurencyjny? Jakie są przewidywane marginesy zysku? Jakie są koszty utraconych korzyści i koszty opóźnienia?
• Decyzje na poziomie komponentów projektu wymagają informacji operacyjnych: Jaki odsetek klientów woli płacić kartą niż przelewem? Jakie są przewidywane koszty operacyjne obsługi przelewów bankowych?
• Decyzje na poziomie szczegółów implementacji wymagają informacji niskopoziomowych: Czy wszystkie pola danych osobowych użytkownika są wymagane do odprawy lotu, czy niektóre pola są opcjonalne i nie musimy ich walidować? Czy potrzebujemy walidacji po stronie backendu z przyczyn związanych z bezpieczeństwem, czy naszym celem jest jedynie poprawa “user experience” i wystarczy nam walidacja po stronie frontendu?

Zbyt drobna dekompozycja jest marnotrawstwem i utrudnia podejmowanie decyzji

Dekompozycja zgrubnego pomysłu na drobne historyjki użytkownika wymaga wiele pracy. Osoby podjemujące decyzje wysokiego poziomu nie potrzebują takich szczegółów. Co więcej, im “grubsze” pozycje backlogu i im dalej w przyszłości się znajdują, tym większa szansa, że zmieni się ich priorytet, zostaną zmodyfikowane albo nawet zupełnie usunięte. A nawet jeśli się tak nie stanie, nie jest możliwe ani opłacalne by spisać wszystkie najdrobniejsze szczegóły tych pozycji. W efekcie, im więcej czasu upłynie pomiędzy dekompozycją a implementacją, tym więcej szczegółów zostanie zapomnianych. Przedwczesna dekompozycja pozycji backlogu jest więc pracą idącą na marne: nie tylko efekty tej pracy nie będą przez nikogo używane, ale będą dodatkowo degradować się i tracić wartość wraz z upływem czasu.

Zbyt drobna dekompozycja pozycji backlogu nie tylko jest marnotrawstwem, utrudnia też podejmowanie decyzji na wysokim poziomie. Kluczowym interesariuszom łatwo jest dyskutować czy lepszą strategią jest sprzedaż biletów lotniczych czy rezerwacji hotelowych. Natomiast jest dla nich praktycznie niemożliwe, by dyskutować co przyniesie większe strategiczne korzyści: walidacja opcjonalnych pól na formularzu rezerwacji lotu, czy dodanie szczegółowych komunikatów błędu na ekranie płatności za rezerwację hotelową – szczególnie, jeżeli backlog zawiera setki tego typu pozycji.

Niedostateczna lub zbyt późna dekompozycja utrudnia development i wymusza późniejsze przeróbki

Z drugiej strony, developerzy pracują najefektywniej z drobnoziarnistymi historyjkami użytkownika i muszą znać wszystkie niskopoziomowe detale. Jeśli historyjki nie są wystarczająco zdekomponowane, developerzy muszą wyjaśniać szczegóły w trakcie implementacji, co powoduje losowe opóźnienia, katastrofalne dla przebiegu sprintu. Ma to negatywny wpływ na prędkość developmentu, przewidywalność i commitment, a w ekstremalnych przypadkach może nawet całkowicie zablokować development.

Implementacja oparta na gruboziarnistych wymaganiach generuje także dodatkową pracę. Jeśli pozycje backlogu są dekomponowane z wyprzedzeniem, jest czas by wyjaśnić albo sprototypować pewne rzeczy, poczekać parę dni na odpowiedź itp. Jeśli jednak wymagania są dekomponowane w trakcie developmentu, nie ma na to wszystko czasu. W efekcie developerzy muszą zgadywać, co owocuje wieloma poprawkami i przeróbkami w późniejszym terminie.

Dekompozycja w odpowiednim stopniu i w odpowiednim momencie: backlog w kształcie piramidy

Idealny backlog produktu musi zachowywać równowagę pomiędzy wszystkimi 3 poziomami pozycji. Górne pzycje, o najwyższym priorytecie, gotowe do developmentu w najbliższym sprincie, muszą być w pełni zdekomponowane, tak by praca developerów mogła iść gładko. Pozycje następne w kolejności muszą być nieco bardziej gruboziarniste, tak by PO mógł priorytyzować poszczególne części projektów obecnie w toku lub mających się w najbliższym czasie rozpocząć. Projekty dalej w przyszłości nie powinny być zdekomponowane, lub powinny być zdekomponowane jedynie minimalnie, by ułatwić strategiczne planowanie. By uniknąć marnotrawstwa, na każdym poziomie dekompozycji powinno być nie więcej pozycji, niż to konieczne.

Często wizualizuje się to jako piramidę, z najmniejszymi pozycjami na górze, trochę większymi w środku i najmniejszymi na dole. W rzeczywistości kształt ten może być nieco zaburzony, ponieważ priorytety się zmieniają i niektóre z już zdekomponowanych pozycji mogą spaść poniżej tych bardziej gruvoziarnistych (lub niektóre z gruboziarnistych mogą zostać podniesione wyżej). Jednakże, nie zdarza się to masowo i nie zamienia backlogu w nieuporządkowany bałagan. Może zdarzyć się, że kilka pozycji na poziomie implementacji spadnie poniżej jednej czy dwóch najwyższych pozycji na poziomie komponentów projektu, albo że pozycja na poziomie komponentu spadnie poniżej pozycji na poziomie projektu. Jednakże rzadko zdarza się to dla więcej niż kilku pozycji i prawie nigdy nie zdarza się, by pozycja na poziomie implementacji spadła poniżej pozycji na poziomie projetku. Jeżeli priorytet jakiejś historyjki użytkownika spadnie aż tak bardzo, powinna ona raczej zostać usunięta z backlogu.

Jak wiele pozycji na każdym z poziomów?

Szczegóły na poziomie implementacji są potrzebne tylko dla pozycji, które będą developowane w najbliższym sprincie. Teoretycznie oznacza to, że “jeden sprint” pozycji powinien wystarczyć. W praktyce jednak potrzebny jest pewien margines na re-priorytyzacje w ostatnie chwili, niewielki bufor na wypadek gdyby zespół developerski zrealizował więcej historyjek niż wstępnie planował itp. W związku z tym, potrzebujemy pozycje na conajmniej 1,5 sprintu, ale nie więcej niż na 2 sprinty by uniknąć marnotrawstwa. Biorąc pod uwagę, że typowy zespół realizue 4-8 historyjek na sprint, przekłada się to na około 6-16 pozycji na poziomie implementacji w backlogu.

Szczegóły na poziomie komponentów projektu są potrzebne dla projektu obecnie w toku i potencjalnie dla kolejnego projektu (zwłaszcza gdy developemnt obecnego zbliża się ku końcowi). Komponenty są większe niż drobnoziarniste historyjki użytkownika, tak więc komponent jest przeważnie wielkości conajmniej połowy lub całego sprintu. Jak poprzednio, wydzielanie większej ilości komponentów niż to niezbędne jest marnotrawstwem, nie powinniśmy więc mieć więcej komponentów niż na około 2 miesiące do przodu. Dla dwu-tygodniowych sprintów przekłada się to na mniej więcej 8-10 pozycji.

Na poziomie projektów rozsądny zakres planowania to 3-6 miesięcy, w ekstremalnych przypadkach do 1 roku, choć osobiście uważam, że rok to zazwyczaj za dużo. Projekty są większe niż komponenty, wielkości co najmniej 1-2 sprintów, więc 3-6 miesięcy projektów oznacza około 3-12 pozycji przy dwu-tygodniowych sprintach.

Sumując wszystkie 3 poziomy, nawet przy uwzględnieniu wyższego zakresu możliwych wartości i dokładając pewien bufor na już zdekomponowane pozycje, których priorytet chwilowo spadł, otrzymujemy backlog nie większy niż około 50 pozycji. Taki backlog jest łatwy do zarządzania i pracy na każdym z poziomów piramidy.

Jak duży jest Twój backlog? Czy masz jakieś reguły na to, jak powinien być zorganizowany? Podziel się swoją opinią w komentarzach poniżej!