Co to jest Backlog Produktu i jakie są jego elementy?

Backlog Produktu jest jedynym źródłem zadań wykonywanych przez Scrum Team. To lista planowanych funkcjonalności Produktu i jego ulepszeń. Jego kształt jest zmienny, a nie wszystkie zadania znajdujące się w Backlogu Produktu zostaną zrealizowane. Backlog Produktu ewoluuje bowiem podczas rozmów z Interesariuszami. Jest również nieustannie doskonalony. Oznacza to, że zadania, których termin realizacji jest najbliższy są w nim przedstawione w sposób bardziej szczegółowy, niż te bardziej odległe.

Wprowadzenie

Product Backlog to największy z Artefaktów Scruma. Odzwierciedla stan pracy nad Produktem w odniesieniu do Celu Produktu. Natomiast po zakończeniu pracy nad Produktem, jego Backlog staje się pełną listą zadań wykonanych przez Scrum Team w celu stworzenia Produktu. Nie zawiera on jednak szczegółowych rozwiązań technicznych.

Co zawiera Backlog Produktu?

Backlog Produktu powstaje podczas spotkań Product Ownera z Interesariuszami. Wyłącznym właścicielem i osobą odpowiedzialną za Backlog Produktu jest Product Owner.

Wpisy w Backlogu Produktu są wyrażane w języku biznesowym. Innymi słowy, opisują one wartość Produktu z punktu widzenia Interesariuszy.

Opisy zadań zawarte w Backlogu Produktu powinny mieć spójny i zrozumiały dla wszystkich charakter. Zawierają one funkcje i udoskonalenia Produktu ujęte najczęściej w formie User Stories, którym poświęcamy osobny wpis. Tutaj wspomnimy tylko, że są to opisy cząstkowych funkcjonalności produktu odpowiadające na pytania o następujące kwestie:

zakres modyfikacji Produktu
cel modyfikacji Produktu
typ użytkownika dla którego ta modyfikacja jest wprowadzana.

Kształt Backlogu Produktu

Kolejność zadań zawartych w Backlogu Produktu zmienia się w miarę rozwijania Produktu. Scrum Team pracując nad Produktem rozwija jego funkcjonalności. Sposób ich realizacji oraz napotykane problemy pozwalają przemyśleć i dookreślić kolejne rozwiązania. Ukończone rozwiązania definiują też i zmieniają porządek powstawania kolejnych, które będą z nich czerpać. Dlatego kolejność ich realizacji jest zmienna. Doskonalenie Backlogu Produktu ma na celu jego bieżącą aktualizację oraz przygotowywanie do wykonania kolejnych zadań. Z tego powodu ma ono charakter ciągły.

Zadania, których termin wykonania jest odległy, są zazwyczaj dużymi, ogólnymi całościami. Ich opis nie zawiera szczegółów, a jedynie zarys funkcjonalności, która powinna zostać zrealizowana. Można wśród nich także znaleźć zadania, które nigdy nie zostaną zrealizowane.

Wpisy w Backlogu Produktu mogą przedstawiać alternatywne rozwiązania. A także pomysły Klienta, które mogą się zdezaktualizować, okazać się nieopłacalne lub z innego powodu nigdy nie wejść w fazę realizacji. Dlatego właśnie Backlog Produktu nazywany jest czasem żartobliwie „listą życzeń Klienta”.

Innym powodem zmian w kształcie Backlogu Produktu jest redefiniowanie rozwiązań. Czasem okazuje się bowiem, że pewien problem znalazł już rozwiązanie przy okazji tworzenia innej funkcjonalności produktu. Lub oczekiwana funkcjonalność stała się zbędna z powodu zmiany innych rozwiązań.

Jednym z podstawowych działań podczas doskonalenia Backlogu Produktu jest dzielenie zadań zawartych w Backlogu Produktu na części. Dzięki temu ogólny zarys funkcjonalności zostaje przedstawiony w postaci mniejszych, bardziej dookreślonych i precyzyjnie zdefiniowanych jednostek.

Zadania przeznaczone do bliższej realizacji stają się bardziej szczegółowe. Stają się także mniejsze, zawierają detale rozwiązań. Szczegóły wyłaniają się w trakcie rozwijania Produktu. Zaś dzięki znajomości aktualnego stanu Produktu oraz bieżących oczekiwań Interesariuszy, Product Owner uzupełnia najbliższe zadania o ich opis, kolejność oraz rozmiar. Oraz wybiera najlepiej opisane zadania do najbliższego Backlogu Sprintu.

Od Backlogu Produktu do Backlogu Sprintu

W toku pracy nad Produktem Product Owner modyfikuje i uszczegóławia Backlog Produktu we współpracy z Zespołem Developerskim. Kierując się sugestiami Product Ownera, podczas Planowania Sprintu Zespół wybiera z Backlogu Produktu funkcjonalności do zrealizowania. Przenosi je wówczas do Backlogu Sprintu oraz dzieli na zadania do wykonania. Zadania przenoszone do Backlogu Sprintu zostają opisane w języku technicznym, czyli w sposób najbardziej przydatny dla Developerów.

Rozmiar zadania jest ważną miarą z punktu widzenia Zespołu Developerskiego. Jego właściwe oszacowanie staje się szczególnie ważne w momencie wybierania User Stories z Backlogu Produktu do Backlogu Sprintu.

Zespół Developerski uczy się z czasem prawidłowo szacować czas i nakład pracy potrzebnej do realizacji określonej User Story. Jest on wyrażany w dniówkach, roboczogodzinach lub Story Points i pozwala oszacować wartość nazywaną Prędkością Zespołu.

Podsumowanie

Backlog Produktu to nieustannie doskonalona lista zadań prowadzących do realizacji Celu Produktu. Treść Backlogu Produktu zwykle wyrażona jest w formie User Stories. Zaś im krótszy czas pozostał do realizacji zadania, tym:

opis zadania jest bardziej szczegółowy
zakres zadania jest mniejszy
zakres zadania jest lepiej zdefiniowany.

Realizacją zadań zajmuje się Scrum Team. Natomiast zarządzanie i modyfikacje Backlogu Produktu należą do Product Ownera.

Zapoznaj się z kolejnym artykułem w serii Przewodnik Scrum – Czym są User Stories?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty