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.
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.
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:
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.
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.
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:
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ść.
Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…
Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…
Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…
Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…
Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…
“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…