W jednym z ostatnich postów o rolach scrumowych opisaliśmy rolę Product Ownera. Jedną z jego podstawowych odpowiedzialności jest zarządzanie Backlogiem Produktu. Co rozumiemy poprzez zarządzanie i w jaki sposób ono następuje?
Zarządzanie… czyli właściwie co?
Do napisania tego tekstu skłoniła mnie próba odpowiedzi na pytanie czym właściwie jest zarządzanie Backlogiem Produktu? Czy w skład zarządzania listą wymagań wchodzi tylko i wyłącznie pisanie User Stories czy również „challengowanie” zespołu, na przykład podczas sesji Backlog Refinementu?
Dla przypomnienia, Backlog Produktu to lista wszystkich cech, wymagań, życzeń czy poprawek błędów, które powinny znaleźć się w tworzonym przez nas oprogramowaniu. Lista ta jest uszczegóławiana, opisywana, szacowana i wartościowana przez cały Scrum Team, chociaż to Product Owner jest jedynym właścicielem backlogu. Odpowiedzialność za priorytetyzację elementów listy również należy do zadań Product Ownera. To on zna wizję produktu i wie, w którym kierunku powinien być rozwijany, aby osiągnąć maksymalną satysfakcję klienta.
Zarządzanie Backlogiem Produktu polegać więc będzie na dodawaniu szczegółów do elementów listy wymagań tak, aby były one maksymalnie rozpoznane i aby spełniały założone kryteria, na przykład zgodne z przyjętymi zasadami Definition of Ready.
Za zarządzanie listą wymagań odpowiedzialny jest Product Owner, skupiając się na maksymalizacji wartości poprzez priorytetyzowanie i nadawanie wartości poszczególnym elementom listy. Tak naprawdę PO „zarządza uśmiechem” na twarzy klienta.
„Odpowiedzialnym za Backlog Produktu, w tym jego treść, dostępność i kolejność elementów, jest Właściciel Produktu.” – Scrum Guide
Ale nie tylko Product Owner pracuje nad Product Backlogiem. Swoją pracę do wykonania ma również Zespół Deweloperski wraz ze Scrum Masterem. W zakres ich odpowiedzialności wchodzą takie czynności jak uszczegóławianie opisu wymagań, dzielenie wymagań na mniejsze (jeśli zachodzi taka potrzeba) czy ich szacowanie.
„Zespół Deweloperski jest odpowiedzialny za wszystkie oszacowania. Właściciel Produktu może wpływać na Zespół Deweloperski pomagając dostrzegać kompromisy i dokonywać
odpowiednich wyborów, ale ostatecznie pracę szacują osoby, które będą ją wykonywać. ” – Scrum Guide
Na zarządzanie Backlogiem Produktu składać się będzie szereg czynności, a każda z ról ma w tym procesie do dołożenia swoją cegiełkę.
Po co to właściwie robimy?
Właściwe zarządzanie listą wymagań da nam odpowiedź na szereg pytań, na które musimy znaleźć odpowiedź jako zespół deweloperski. Nietrudno sobie też wyobrazić, jakie mogą być negatywne konsekwencje złego zarządzania Backlogiem Produktu. Brak wizji na rozwój, brak spojrzenia Big Picture czy brak możliwości realnego zaplanowania kolejnego sprintu to tylko niektóre z nich. Pracując nad listą wymagań, niezwykle ważne jest aby wszyscy mieli świadomość że:
„Backlog Produktu nigdy nie jest kompletny. Jego wczesna wersja nakreśla początkowo znane i najlepiej rozumiane wymagania. Backlog Produktu ewoluuje wraz z produktem i środowiskiem, w którym ten produkt będzie używany.” – Scrum Guide”
Zarządzanie polegające na priorytetyzacji elementów listy wymagań pozwoli nam na ustalenie kolejności ich realizacji. To z kolei odpowiada na pytanie, które z funkcjonalności przewidzianych do realizacji w naszym systemie są w chwili obecnej najważniejsze z punktu widzenia naszego klienta. Odpowie nam to również na pytanie, ukończenie których wymagań spowoduje maksymalizację jego zadowolenia. Miejmy jednak z tyłu głowy, iż maksymalizacja zadowolenia klienta nie oznacza spełnienia wszystkich jego wymagań. Najważniejsze są te, które pozwolą nam stworzyć Minimum Viable Product.
Takie zdefiniowanie wymagań, aby możliwa była ich realizacja podczas sprintu, to również zarządzanie Backlogiem Produktu. Te proste zdanie bardzo precyzyjnie określa poziom szczegółowości znajdujących się w backlogu elementów. Jako odpowiedzialny za wykonanie swojej pracy zespół musimy wiedzieć co jest do zrobienia w kontekście konkretnego wymagania (opis), ile czasu zajmie nam realizacja tego wykonania (szacowanie) oraz jaką wartość dla naszego klienta ma element listy.
Zarządzanie Backlogiem Produktu ma ogromne znaczenie dla powodzenia naszej pracy. Bez niego możemy porwać się z motyką na słońce (zbyt duże lub nierozpoznane wymagania), spędzić czas na robieniu nieistotnych rzeczy (priorytet, wartość) lub zmierzać w kierunku niezgodnym z wizją Product Ownera.
Metody zarządzania Backlogiem Produktu
Warto wspomnieć, że tak samo jak w przypadku innych aspektów związanych ze Scrum (patrz np. sposób zapisu wymagań) Scrum Guide nie narzuca jak ma zarządzanie Backlogiem Produktu ma wyglądać. Mamy więc pełną dowolność w tym zakresie, o ile oczywiście osiągniemy założone efekty.
Jednym ze sposobów zarządzania może być opisany przez nas ostatnio Triage, czyli klasyfikacja elementów listy wymagań według wcześniej określonych kryteriów. Wariacją Triage może być metoda MoSCoW, czyli priorytetyzacja elementów listy wymagań w oparciu o kategorie: Must/Should/Could/Won’t.
Do metody MoSCoW oraz innych metod zarządzania i priorytetyzacji Backlogu Produktu wrócimy w jednym z kolejnych wpisów na blogu.
Słowo na koniec
Należy podkreślić, że czynności związane z zarządzaniem Backlogiem Produktu są niezwykle istotne z punktu widzenia realizowanego przedsięwzięcia, jakim jest nasz projekt. Właściwe zarządzanie listą wymagań daje komfort wszystkim uczestnikom procesu wytwarzania oprogramowania. Mówiąc o uczestnikach procesu wytwarzania mam na myśli zarówno klienta będącego odbiorcą naszych prac jak również Zespół Scrumowy.
To niepewność jest głównym źródłem braku komfortu. Dobrze zarządzany backlog odpowiada na pytanie „kiedy mniej więcej będziemy się czym zajmować” – przy czym im bliższa data, tym dokładniejsze oszacowanie.
Proces zarządzania Backlogiem Produktu nigdy się nie kończy. W każdej chwili możemy dodać lub usunąć z listy wymaganie, tak samo ciągle ulegają zmianie atrybuty poszczególnych elementów. Nie możemy założyć, że w ramach któregokolwiek ze spotkań scrumowych będziemy w stanie wykonać całe te zadanie.
Pamiętajmy więc, aby przyłożyć do procesu zarządzania backlogiem należytą atencję i w żadnym wypadku go nie pomijać. Może to doprowadzić do przykrych konsekwencji.
