Jeden produkt to jeden backlog. Tak powinno być i tak jest w wielu miejscach, które przyszło nam oglądać. Czasami jednak można spotkać organizacje i zespoły, które próbują jakoś działać mając dwa lub trzy backlogi. Są też takie, gdzie jest ich dziesięć…
Ukryte Backlogi
„Jak to?!”, wykrzyknie pewnie wielu z Was. „To niemożliwe, żeby gdziekolwiek ktokolwiek próbował działać na dziesięciu backlogach na raz!” Dobrze jednak wiemy, że jak dostatecznie długo poszukamy, to znajdziemy każdą możliwą sytuację, przewinienie i każdy ScrumBut.
Zacznijmy jednak od bardziej łagodnej i typowej sytuacji, gdzie tych backlogów mamy dwa lub trzy. Nadal wydaje się to nieprawdopodobne? Spróbujmy więc wyobrazić sobie sytuację, w której na Planowaniu Sprintu wyciągamy z listy błędów te, które będziemy poprawiać w najbliższej iteracji, a potem dopiero zabieramy się za dorzucanie elementów z Backlogu Produktu, żeby wypełnić nasze Capacity.
Tu już pewnie niektórzy mogą poczuć się przynajmniej niespokojnie. Prace rozwojowe w backlogu, błędy na osobnej liście, a refactory i kwestie czysto techniczne gdzieś osobnym narzędziu. No i nie zapomnijmy o akcjach po Retro, które pewnie leżą gdzieś w Zintegrowanym Systemie Do Zarządzania Wrzechświatem, czyli Excelu.
Niech mi ktoś spróbuje powiedzieć, że to nie są różne backlogi.
„One Backlog to rule them all…”
Wróćmy do podstaw. Jeden Produkt ma jednego Product Ownera, jeden Cel Produktu oraz jeden Backlog. O tym co się może stać, gdy będzie Dwóch Product Ownerów mówiliśmy w jednym z naszych filmów. Sytuacja, w której mamy kilka Backlogów bardzo przypomina tą, gdzie posiadamy kilku PO.
Jako Zespół potrzebujemy mieć jasno sprecyzowaną ważność rzeczy, którymi się zajmujemy. Dzięki posiadaniu jednego backlogu nie musimy ciągle pytać wszystkich dookoła, która lista ma priorytet nad którą. Wszystkie te poboczne listy „rzeczy do zrobienia” musimy zebrać w jedno. Nawet jeżeli dotyczą kilku różnych systemów albo nawet projektów.
„Ale to zajmuje strasznie dużo pracy!” Prawda, ale jest to praca z gatunku tej, którą i tak trzeba będzie wykonać. Żebyśmy mogli się skutecznie zaplanować i tak będziemy musieli porównać czy błąd #1 z listy bugów jest ważniejszy niż pierwsze wymaganie z backlogu. Następnie porównamy go z długo odwlekanym refactorem kodu i innymi rzeczami z pogranicza długu technologicznego. Potem przejdziemy albo do błędu #2 albo do jakiegoś wymagania z backlogu.
Jeżeli powyższy proces będziemy chcieli przeprowadzić na Planowaniu Sprintu, to zajmie nam ono strasznie dużo czasu. Co gorsza, jeżeli nadal uważamy, że posiadanie kilku niezależnych list wymagań jest ok, to problem pojawi się także na refinementach. Bo co ten „biedny zespół” ma tak naprawdę rozpoznawać? Błędy z listy błędów? Wymagania z listy wymagań? Zgłoszenia z listy zgłoszeń od interesariuszy? Uwagi od klientów z listy uwag od klientów?
Szybkie rozwiązania
Postawmy sprawę jasno – i tak ktoś kiedyś będzie musiał powiedzieć „element A jest ważniejszy od elementu B”. A skoro tak, to my wiemy kto jest tym „kimś” i kiedy ma to zrobić. Niech Product Owner po prostu robi to, co do niego należy i zarządza Backlogiem Produktu.
Najprostsze rozwiązanie tego problemu to ustalenie „ważności” poszczególnych backlogów i następnie połączenie ich w jedną całość. Tzn. ustalamy, że błędy krytyczne są na szczycie, potem wszystkie rzeczy rozwojowe, potem błędy niekrytyczne, potem…
Sami chyba czujemy, że to się nie uda.
Jakiś błąd niekrytyczny może być ważniejszy niż kilka wymagań, a inny może być ulokowany gdzieś na samym dnie backlogu. Nie ma prostego sposobu na posprzątanie tego bałaganu, niż konsekwentne i systematycznie sprzątanie całości. Wszystkich list udających backlogi. I to faktycznie jest zadanie dla naszego „biednego” Prodcut Ownera. Jak coś jest przeznaczone do realizacji – trafia do jednego backlogu.
A co z wymaganiami dopiero co zgłoszonymi przez interesariuszy?
Jeszcze jeden Backlog
Czasami zdarza się, że Product Owner bądź sam zespół utrzymuje i zarządza swoistą „poczekalnią”. Jest to lista wymagań, które dopiero do nas wpadły i które są zbyt mało rozpoznane, żeby można było je zrealizować. Nie potrafimy ich wycenić, nie do końca czujemy, o co w nich chodzi i czy w ogóle da się je zrobić. Po co więc zaprzątać sobie głowę ich kolejnością w Backlogu Produktu?
Z jednej strony, skoro są to rzeczy nierozpoznane, to pewnie nie są przeznaczone do realizacji w najbliższej przyszłości. A skoro tak, to możemy umieścić je odpowiednio nisko i się nimi nie przejmować. Z drugiej strony, to według kolejności w Backlogu zespoły wykonują refinement. A to z kolei znaczy, że może też do nas trafić nowe wymaganie, które należy jak najszybciej przygotować do zaplanowania. Czyli jednak wyląduje na szczycie listy.
Backlog składający się z setek elementów nie jest niczym niespotykanym. Aby nie marnować czasu na refinement rzeczy, których i tak nie będziemy robić, także i te „nowe, nierozpoznane” rzeczy powinny być umieszczone w odpowiednim miejscu. Bo to też nam daje odpowiedź na pytanie „czy musimy więcej czasu poświęcać na refinement, czy wystarczy, że będziemy robić, to co już mamy rozpoznane?”
W planowaniu i zarządzaniu tak skonstruowanym backlogiem, zawierającym rzeczy gotowe i niegotowe, może pomóc nam Defintion of Ready. Czasami używane jest ono błędnie, jako narzędzie walki z Product Ownerem, „żeby nam nie dorzucał do Sprintu”. Jeśli jednak chcemy zapanować nad dużym backlogiem, zawierającym tematy o różnym stopniu gotowości, polecam artykuł o DoR.
Pamiętajcie jednak, że zanim zaczniemy wprowadzać takie elementy, najpierw jednak musimy mieć jeden backlog.
Ja bym się tu zainspirował DSDMemem i uruchomił priorytetyzację MoSCWą. Jeśli jest coś bez czego rozwiązanie nie działa, nie ma sensu, jest nielegalne albo niebezpieczne to to jest Must-have. Itd. Dla każdego poziomu priorytetu są definicje. Z punkty widzenia biznesowego priorytetyzuje PO, z punktu widzenia architektonicznego i technicznego zespół. Ja bym całość jeszcze poprzedził takim warsztatem w stylu JAD, z udziałem kluczowych interesariuszy.