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.
Backlog Produktu – omówione zagadnienia:
- Wprowadzenie
- Co zawiera Backlog Produktu?
- Kształt Backlogu Produktu
- Doskonalenie Backlogu Produktu
- Podsumowanie
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ść.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?