Z dobrej kondycji Backlogu Produktu wynika w Scrumie cała masa korzyści, z których najważniejszymi są większa skuteczność Zespołu i możliwość wytwarzania lepszego produktu. Jeśli Backlog jest w marnym stanie, negatywne konsekwencje są niemal nieuniknione (ich omówienie zasługuje na osobny artykuł).
Pisząc o kondycji Backlogu, mam na myśli obecność, niedostatek lub całkowity brak kluczowych cech tego artefaktu. Można ich określić aż dziesięć, a stworzona w ten sposób lista stanowi dobrą podpowiedź tego, o co zadbać trzeba, aby powstał dobry Backlog Produktu.
1. Plan osiągnięcia Celu Produktu
Backlog Produktu to uporządkowana lista zmian, jakich Product Owner zamierza dokonać w produkcie, aby osiągnąć wytyczony Cel Produktu.
Nie jest to więc zbiór rzeczy do zrobienia, do którego dorzucane są kolejne elementy, które „kiedyś zostaną zrealizowane”. Backlog musi wyjaśniać, w jaki sposób Product Owner chce wraz z Zespołem Scrum osiągnąć Cel Produktu. Płyną stąd trzy wnioski.
Pierwszy: Cel Produktu nie może być nieokreślony i musi być jeden. Jeśli Cel nie zostanie nazwany, Product Owner nie będzie miał czym kierować się przy ustalaniu zawartości i kolejności Backlogu Produktu. Jeśli zdefiniowany zostałby więcej niż jeden Cel Produktu naraz, nie będzie możliwe takie ukształtowanie Backlogu Produktu, by wszystkie z nich jednocześnie osiągać – w efekcie albo i tak obowiązywał będzie jeden z nich, albo żaden.
Drugi wniosek: Cel Produktu musi być zawarty w jakiejś formie w samym Backlogu Produktu, który z niego wynika (taki wymóg definiuje zresztą wprost Scrum Guide). Chodzi o to, by każdy, kto ma dostęp do Backlogu, widział od razu Cel Produktu i mógł ocenić, w jakim stopniu plany Product Ownera (odzwierciedlone listą elementów) pozwalają ten Cel osiągnąć. W ten sposób Product Owner może liczyć na merytoryczny feedback od interesariuszy i tym samym realną pomoc przy zarządzaniu Backlogiem.
Trzeci i ostatni wniosek: skoro Backlog Produktu to plan osiągnięcia Celu Produktu, powinny się w nim znajdować tylko elementy, które temu służą lub muszą zostać zrealizowane, by produkt w ogóle nadawał się do użycia. Inaczej mówiąc, w Backlogu nie powinno być „pomysłów na przyszłość”, które będą w nim zalegać potencjalnie w nieskończoność.
2. Jedyne źródło zmian funkcji i cech produktu
Backlog Produktu stanowić powinien jedyne źródło zmian w produkcie, które polegają na:
- wytworzeniu nowych funkcjonalności produktu lub nadaniu mu nowych właściwości (cech użytkowych),
- modyfikacji sposobu działania mechanizmów, które w produkcie już istnieją lub zmianie właściwości, które produkt aktualnie posiada,
- usunięciu z produktu niepotrzebnych funkcji lub pozbawienie go niepożądanych cech użytkowych.
Każdy element Backlogu Produktu (ang. Product Backlog item, w skrócie PBI) co do zasady powinien opisywać jedną zmianę, której wprowadzenie do produktu przybliży osiągnięcie obowiązującego Celu i przyniesie korzyści interesariuszom (np. użytkownikom).
Korzyści oczywiście nie są tutaj automatycznie synonimem pieniędzy – mogą mieć wymiar niefinansowy i polegać na poprawie bezpieczeństwa, zwiększeniu wygody użytkowania, ułatwieniu jakiegoś działania dzięki użyciu produktu itd.
Oczywiście budowanie produktu wymaga również dokonywania w nim zmian czysto technologicznych, które służą umożliwieniu dalszego rozwoju oraz naprawiania błędów. Większość tego typu prac stanowi po prostu bieżący development i jest opisana elementami Backlogu Sprintu, a nie Backlogu Produktu. Co nie znaczy, że w tym ostatnim Backlogu nie mogą się znaleźć np. zgłoszenia błędu – jak najbardziej ma to sens w przypadku problemu, którego naprawa nie jest pilna, ale będzie kosztowna, więc Product Owner chce wybrać moment, kiedy to nastąpi.
Można więc powiedzieć, że Developerzy mogą dokonywać w produkcie zmian funkcjonalności lub właściwości użytkowych tylko na podstawie elementów Backlogu Produktu, ale mają jednocześnie prawo i obowiązek dokonywać wszelkich innych zmian, które uznają za uzasadnione (np. udoskonalenie implementacji), mimo braku opisujących je elementów w Backlogu Produktu.
3. Minimalny, ale wystarczający
Jeśli Cel Produktu jest sensowny i nie stanowi rozmytego hasła, z którego niewiele wynika, Backlog Produktu nie będzie przesadnie rozbudowany. W miarę, jak w serii kolejnych Sprintów Zespół przybliża się do osiągnięcia aktualnego Celu Produktu, Backlog powinien się zmniejszać, co stanowi jedną z metod oceny postępów prac.
Gdy Cel zostanie osiągnięty, niemal zawsze w Backlogu pozostają jeszcze elementy – te, które z jakiegoś powodu muszą być zrealizowane, ale nie były związane z Celem Produktu. Po wytyczeniu nowego Celu Product Owner dostosowuje Backlog tak, by odzwierciedlał on sposób osiągnięcia tego Celu.
Może też zdarzyć się, że Cel Produktu, zanim jeszcze zostanie osiągnięty, zostanie zastąpiony nowym Celem. Również wtedy Product Owner powinien bezwzględnie dostosować zawartość i kolejność Backlogu Produktu tak, by odzwierciedlał on ów nowo wyznaczony Cel.
4. Ciągle zmienny i wyłaniający się z upływem czasu
Backlog Produktu to plan prac nad Celem Produktu, ale nie należy utożsamiać go z planem projektu (choć niestety często się to zdarza). Po wyznaczeniu Celu Product Owner nie jest przecież w stanie z góry przewidzieć, co trzeba będzie zrobić, aby Cel ten osiągnąć. Ba, nie jest nawet w stanie z dużą dozą pewności twierdzić, że to, co umieścił na liście, poukładał w dobrej kolejności.
To oznacza, że Product Owner zawsze wizualizuje w Backlogu decyzje wynikające z aktualnie posiadanej wiedzy. W miarę, jak prace nad Celem Produktu postępują, ujawniają się potrzeba zmiany zawartości i kolejności elementów Backlogu. Jest to więc plan wyłaniający się (ang. emergent plan), a nie statyczna lista rzeczy do zrobienia w określonej kolejności.
5. Uporządkowany w kolejności realizacji elementów
Backlog Produktu nie jest zbiorem o dowolnej formie, ale stanowić musi stanowić uporządkowaną listę (ang. ordered list), której elementy ułożone są wedle określonego klucza. Co oczywiste, lista nie może zawierać dwóch elementów na tej samej pozycji.
Kluczem, wedle którego porządkowane są elementy, jest oczekiwana przez Product Ownera kolejność realizacji. Wynika ona z różnych czynników, które Product Owner musi wziąć pod uwagę. Przykładową ich listę prezentuję poniżej:
- ważność konkretnego elementu dla interesariuszy,
- korzyści z jego realizacji lub koszt wynikający z jej braku,
- jak pilna jest ta zmiana i czy istnieje jakaś data graniczna na jej wykonanie (ang. deadline),
- koszt implementacji, w tym jej czasochłonność,
- zależności pomiędzy poszczególnymi elementami,
- zależności od innych produktów, komponentów, narzędzi i dostępności materiałów.
Często słyszy się o priorytetyzacji Backlogu, ale to nie oddaje poprawnie sposobu, w jaki Product Owner zarządza tym artefaktem. Poszczególne elementy mogą mieć przecież taki sam priorytet, ale na jednowymiarowej liście nie znajdą się nigdy na jednej pozycji. Trzeba więc znaleźć inne kryteria oceny i na ich podstawie ustalić ostateczną kolejność realizacji elementów.
Stąd też należy raczej mówić o porządkowaniu Backlogu Produktu i nie utożsamiać tego określenia ze sprzątaniem, ale z podejmowaniem decyzji o kolejności (porządku) elementów na liście.
6. Przejrzysty
Każdy, kto ma dostęp do Backlogu Produktu, może zgłosić Product Ownerowi uwagi odnośnie do zawartości lub kolejności elementów na liście. W ten sposób możliwe staje się szybkie wychwycenie, że Backlog miernie odzwierciedla potrzeby interesariuszy lub obowiązujący Cel Produktu.
To wymaga, by Backlog Produktu był przejrzysty, czyli muszą jednocześnie być spełnione wszystkie poniższe warunki:
- Cel Produktu jest zrozumiały i zawarty w Backlogu,
- wszyscy widzą taką samą listę elementów,
- wszyscy widzą elementy w tej samej kolejności,
- elementy opisane są w zrozumiały sposób.
Trzy pierwsze warunki są dość oczywiste, czwarty wymaga komentarza. Elementy Backlogu Produktu bezwzględnie muszą być zrozumiałe dla Zespołu Scrum. Natomiast ciężko liczyć na feedback od interesariuszy, jeśli nie będą oni w stanie zidentyfikować swoich potrzeb na liście albo nie rozumieją Celu Produktu. Najlepiej, aby potrafili zrozumieć większość lub wszystkie elementy, bo wtedy możliwa jest efektywna dyskusja o tym, czy Cel Produktu jest właściwy, jaki jest postęp prac nad nim i czy plan jego osiągnięcia jest dobry.
7. Dostępny
Żadne rozważania o Backlogu Produktu nie mają sensu, jeśli nie jest on dostępny dla interesariuszy i Zespołu Scrum. Nie może być tak, że uzyskanie wglądu w Backlog wymaga umówienia się z Product Ownerem, który wtedy ujawnia, co znajduje się na liście i jaki jest aktualny Cel Produktu. Nie może być też tak, że dostępne są jedynie wybrane fragmenty Backlogu, bo wtedy staje się on automatycznie nieprzejrzysty.
Oczywiście są sytuacje, w których dostępność dla interesariuszy musi być ograniczona, bo np. są konkurentami na rynku, a korzystają z jednego produktu. Dlatego dostępność Backlogu nie jest nigdy bezwarunkowa, ale zawsze powinna być maksymalnie szeroka.
Natomiast nie ma nigdy uzasadnienia dla ograniczenia dostępności Backlogu Produktu dla Zespołu Scrum lub Zespołów, które nad rozwojem tego produktu pracują. To uniemożliwiałoby lub utrudniało pielęgnację Backlogu Produktu, a tym samym przygotowanie się do planowania Sprintów.
8. Wystarczająco, ale nieprzesadnie szczegółowy
Aby interesariusze mogli zrozumieć zawartość Backlogu Produktu, poszczególne elementy nie mogą być zdefiniowane w sposób zbyt techniczny albo wręcz skupiać się na implementacji. Nie mogą też zostać przesadnie rozdrobnione, bo wtedy będzie ich zbyt wiele, a jednocześnie każdy opisany będzie bardzo detalicznie. Ciężko wtedy zrozumieć, dokąd zmierza rozwój produktu.
Ważne jest też, by Product Owner mógł łatwo dostosowywać zawartość Backlogu Produktu, gdy ujawni się taka konieczność. To oznacza, że elementy muszą być na tyle niezależne od siebie, w jakim stopniu to w ogóle możliwe. Zbytnie rozdrobnienie elementów i szczegółowe opisy temu nie sprzyjają.
W praktyce oznacza to, że elementy znajdujące się na początku listy (te, które będą realizowane już niedługo), są z reguły mniejsze i bardziej szczegółowo opisane, niż te, które implementowane będą później (o ile w ogóle to nastąpi).
W szczególności to dodatkowy powód, by nie przesadzać z upychaniem w elementach Backlogu od razu mnóstwa informacji. To wymaga czasu i często wiąże się z podejmowaniem decyzji na podstawie aktualnie posiadanej wiedzy. Nie jest jednak wykluczone, że do momentu realizacji konkretnego elementu, nastąpią zmiany, które uczynią wszystkie poczynione ustalenia nieaktualnymi i trzeba będzie pracę wykonać raz jeszcze. A jeśli element ostatecznie okaże się zbędny, wysiłek włożony w jego pielęgnację będzie czystym marnotrawstwem.
Z podziałem dużych elementów na kilka mniejszych też nie warto się spieszyć, bo z czasem może okazać się, że ostatecznie trzeba dokonać go inaczej. Nie mówiąc już o tym, że doprowadzi to do eksplozji liczby elementów na liście, co znacząco utrudni zarządzanie Backlogiem i nie wpłynie dobrze na jego przejrzystość.
9. Opisujący potrzeby i problemy interesariuszy
Ważny jest sposób, w jaki definiowane są poszczególne elementy Backlogu Produktu. O ile nie ma istotnego znaczenia, czy użyte zostaną np. historyjki użytkownika (ang. user stories), klasyczne wymagania czy jeszcze coś innego, o tyle każdy element powinien opisywać problem interesariuszy, który należy rozwiązać, albo ich potrzebę, którą zmiana w produkcie pozwoli zaspokoić.
Częstym błędem jest opisywanie prac nad produktem z punktu widzenia wykonawcy. Przykładowo, jeśli tworzony jest latający dron, najpierw można zintegrować firmware ze sprzętem, potem z oprogramowaniem sterującym, następnie zaimplementować odczyt sygnałów z czujników i reakcję na nie, komunikację z pilotem itd. Może to spowodować, że przez bardzo długi czas nie powstanie żaden latający dron, a jedynie jego komponenty, które nie są do niczego używane, ale „już są gotowe”. Najczęściej potem okazuje się, że mnóstwo tych „gotowych” rzeczy trzeba przerabiać.
Dużo lepiej jest sporządzać elementy Backlogu Produktu, posługując się perspektywą użytkownika produktu. Przykładowy dron najpierw musi po prostu wystartować, potem reagować na polecenia pilota, wreszcie wrócić do miejsca startu, a następnie wylądować. Dzięki temu już na początku dron zacznie latać, choć pewnie roztrzaska się popisowo ze względu na brak sterowania, więc trzeba testować go w odpowiednich warunkach. To wymaga więcej wysiłku od Developerów, ale za każdym razem wytworzone mechanizmy będą realnie walidowane i jeśli trzeba od razu modyfikowane.
Najpodlejszą formą elementów Backlogu Produktu są zadania, a więc opisy czynności, jakie mają wykonać Developerzy. Nie dość, że redukują Developerów do wykonawców, którzy nie mają wpływu na to, co robią (ucierpieć może na tym zaangażowanie), to jeszcze tworzenie takich zadań jest czasochłonne i wymaga podjęcia z dużym wyprzedzeniem szeregu decyzji, z których potem ciężko się będzie wycofać, bo tworzą cały łańcuch zależności.
Oczywiście nawet w najlepszym Backlogu trafią się zadania lub elementy, które związane są nie tyle z potrzebami interesariuszy, ile z technologicznym rozwojem produktu. Niemniej Backlog Produktu co do zasady nie jest narzędziem do planowania prac developerskich, ale do planowania rozwoju produktu – osiągania wytyczonego Celu Produktu. Zwykle istnieje szereg alternatywnych dróg, by ten Cel osiągnąć, a Backlog nie powinien przedwcześnie wskazywać na jedną z nich.
10. Służy empirycznej kontroli procesu rozwoju produktu
Product Owner odpowiada za Backlog Produktu albo – jak powiedzą niektórzy – zarządza nim. Przy czym chodzi tu o zarządzanie w rozumieniu anglojęzycznego terminu management, wywodzącego się od czasownika manage – po polsku: powodować coś, doprowadzać do czegoś. Zarządzanie należy więc rozumieć jako doprowadzenie do tego, by Backlog Produktu miał cechy takie, jakie mieć powinien i by efektywnie służył celowi, dla którego powstaje.
A celem tym jest uczynienie planów rozwoju produktu przejrzystymi dla Zespołu Scrum i interesariuszy, co wymaga przejrzystości Backlogu, jego dostępności i nadania mu formy uporządkowanej listy. To wymaga również regularnego sprawdzania i dostosowania tego artefaktu, jeśli okaże się to potrzebne.
Jak każdy artefakt w Scrumie, tak i Backlog Produktu ma właśnie taką funkcję: stanowi podmiot sprawdzenia, który pozwala na empiryczne (oparte o efekty tego sprawdzenia) podejmowanie decyzji – czyli adaptację. Sprawdzać można między innymi:
- czy Cel Produktu jest wciąż aktualny i zbieżny z oczekiwaniami interesariuszy,
- w jakim stopniu został już osiągnięty,
- w jaki sposób Product Owner zamierza go osiągnąć z Zespołem (lub Zespołami),
- czy plan (zawartość i kolejność elementów Backlogu) faktycznie prowadzi do osiągnięcia Celu Produktu,
- czy poszczególne elementy dobrze odzwierciedlają potrzeby interesariuszy i ich problemy,
- czy Backlog jest zrozumiały dla interesariuszy i Developerów.
W szczególności można i należy poddawać sprawdzeniu również i to, czy Backlog jest wystarczająco przejrzysty i dostępny, a jeśli okaże się, że nie, zadbać o to.
Adaptacja polega natomiast na ustaleniu kolejności i zawartości Backlogu Produktu, w tym również na definiowaniu Celu Produktu. Odpowiada za to Product Owner, choć operacyjnie może upoważnić kogoś (np. Developerów) do wykonania części prac, zachowując pełną odpowiedzialność za jej skutki.
Ciąg dalszy nastąpi
W kolejnym artykule, który opublikowany zostanie już wkrótce, napiszę o typowych błędach w pracy z Backlogiem Produktu, jakie popełniają Product Ownerzy i całe Zespoły, a także o opłakanych skutkach, jakie to powoduje.