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:

  1. Wprowadzenie
  2. Co zawiera Backlog Produktu?
  3. Kształt Backlogu Produktu
  4. Doskonalenie Backlogu Produktu
  5. 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.

What is the Product Backlog?

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.

Scrum Guide | 18. Co to jest Backlog Produktu? caroline becker avatar 1background

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:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?