Jak porządkować Product Backlog? — część II

Kontynuujemy rozważania na trudną techniką porządkowania  Product Backlog (Rejestr Produktu jeśli wolisz po polsku). Szereg czynników jakie Product Owner musi wziąć pod uwagę omówiliśmy w pierwszej części artykułu.

Spójność Dewelopmentu

Największą wartością domu jest dach, ale jednak budujemy domy zaczynając od fundamentów. Budowanie systemów informatycznych różni się od budynków. Dzięki różnym technologiom i frameworkom nie musimy kłaść fundamentów. Jednak są pewne ograniczenia. Czasem łatwo jest zbudować funkcjonalność przy okazji budowania innej. Zatem warto przejrzeć Product Backlog i uporządkować funkcjonalności względem spójności i łatwości implementacji.

Z drugiej strony trzeba uważać, żeby nie wpaść w pułapki scrum-waterf-fail. Bardzo łatwo jest popaść w patrzenie na produkt tylko i wyłącznie od strony technicznej. Developerom zazwyczaj najłatwiej jest budować system od najniższych warstw, architektury albo swoje osobne klocki. Może też dojść do podzielenia systemu ze względu na poziome warstwy rozwiązania zamiast obszary funkcjonalne. Ale takie podejście nie daje wartości z punktu widzenia klienta czy użytkownika i powoduje problemy z integracją. Pamiętaj, że celem każdego Sprintu jest zbudowanie działającego, użytecznego, zintegrowanego Przyrostu Produktu w stanie gotowym do wdrożenia. Nie zawsze warto się wdrożyć po danym Sprincie.

Spójność Biznesowa

Największą wartością w platformie e‑commerce są płatności, ale niestety potrzebujemy wyświetlanie towarów i koszyk zanim ktoś nam zapłaci. Musimy być jakaś kolejność działań, skończona ścieżka w workflow. Produkt, z którego nie można w pełni korzystać lub posiada ślepe zaułki spowoduje frustrację użytkownika. Kiepskim pomysłem też tworzenie fałszywego wrażenia. Kiedyś pracowałem z Product Ownerem, który postanowił umieścić zaślepione ekrany dla planowanych dopiero funkcjonalności. Nie skończyło to się dobrze dla niego ani dla produktu. Przy takim podejściu łatwo też się zgubić w tym co jest zrobione a co nie jest i jak nam idzie.

Zależności Zewnętrzne

Zespoły Scrum pracują najlepiej kiedy nikt im nie przeszkadza, czyli nie mają wrzutek, bieżączki. Zespoły Scrum pracują najlepiej również kiedy nie mają zależności zewnętrznych. A czasem zdarza się, że mamy zewnętrznego dostawcę w ramach systemu. Nie jest powiedziane, że ten dostawca, a nawet inny zespół pracuje w Agile. Powstają zależności. Na przykład nasz zespół może dostarczyć funkcjonalność dopiero kiedy inny dostarczy swoją część albo udostępni API. Oczywiście trzeba się dogadać kiedy ten drugi zespół prognozuje dostarczyć swoją część. Nie rozsądnym jest zakładać, że tak napewno będzie. To tylko prognoza. Jeśli prognoza mówi, że drugi zespól dostarczy w Sprincie piątym, to planujemy, że my zaczniemy w Sprincie siódmym. Taka zależność oczywiście wpływa nam na porządek elementów związanych z tą funkcjonalnością na Product Backlog.

Spójność Wdrożenia

Nic tak nie wkurza użytkownika jak nowa wersja systemu, która zawiera bug-fixing i różne zmiany. Dużo lepiej jest odbierana nowa wersja, która ma sens, wprowadza coś konkretnego. Może pojawi się też konieczność przeszkolenia użytkowników. Możliwe, że wdrożenie nowej wersji wymaga dużo pracy i oficjalnego procesu. Product Owner powinien mieć wizję kolejnych wydań. Z wizji wydań powinny w prosty sposób wynikać Cele Sprintów. Zespół, który wie jaki jest sens jego pracy jest bardziej zmotywowany. Roadmapa produktu powinna być jasno odzwierciedlona w kolejności elementów Backlogu Produktu.

Inne Czynniki

Jest jeszcze całe mnóstwo czynników, które Product Owner powinien wziąć pod uwagę, żeby właściwie ułożyć Product Backlog. Niektórzy zbudują sobie w tym celu “magiczny” wzór w arkuszu kalkulacyjnym, a inni będą robić to na wyczucie. Zdarza się, że pomimo ułożonego porządku trzeba zrobić wyjątek. Właściciel Produktu zarządza oczekiwaniami interesariuszy i obojętnie jakie decyzje podejmie, zawsze będzie ktoś niezadowolony.

Mówienie Nie

Product Owner ma w swoich rękach bardzo potężne narzędzie, z którego rzadko zdaje sobie sprawę, a jeszcze rzadziej korzysta.Każdy może umieszczać elementy na liście Product Backlog, ale Product Owner może je bardzo szybko usunąć. Właściciel Produktu może odmówić wykonania PBI jeśli nie widzi w tym sensu.

Kiedyś miałem managera, który po powrocie z urlopu usuwał wszystkie nieprzeczytane maile. Jeśli to coś ważnego, to przecież nadawca sam się przypomni ponownie. Dobrą praktyką jest także okresowe przeglądanie Backlogu i usuwanie stary elementów. Zasada przydatności do spożycia 6 miesięcy sprawdza się tutaj bardzo dobrze. Jeden z Product Owner usunął hurtowo wszystkie elementy z ID poniżej 1000. Byliśmy w Sprincie w okolicy ID 1500, więc to co jest poniżej tysiąca na pewno jest stare.  Jeśli przez sześć miesięcy czegoś nie zrealizowaliśmy i ciągle dostaje niski priorytet, to prawdopodobnie nigdy tego nie zrobimy. A co jeśli ktoś sobie przypomni o tym elemencie i będzie chciał, żeby Zespół Developerski go zrealizował? Jeśli to jest takie ważne, to taka osoba może utworzyć go ponownie.

Czy to wszystkie zmienne, które Product Owner musi brać pod uwagę? Na pewno nie. Więcej w poprzedniej części artykułu.