Rejestr Produktu (ang. Product Backlog) zwany czasem zaległościami produktu, to główny wykaz wszystkich funkcjonalności pożądanych w produkcie. Za dostarczenie wymagań w postaci rejestru produktu odpowiedzialny jest Właściciel Produktu. Rejestr produktu to „spis czekających na wykonanie historyjek z rejestru produktu z przypisanymi priorytetami” [1]. Podczas inicjacji projektu mamy jego zarys. Nie ma możliwości i wiedzy by projekt był dokładnie zdefiniowany. Zazwyczaj podczas inicjacji projektu w rejestrze produktu zapisuje się to, co jest oczywiste, co niemal zawsze wystarcza do pierwszego sprintu. Product Backlog, wraz z upływem czasu, zwiększa swoją objętość adekwatnie do poszerzanej sukcesywnie wiedzy jaką ma Właściciel Produktu.
„Rejestr produktu zastępuje coś, co w tradycyjnych projektach nazywaliśmy wymaganiami użytkownika lub specyfikacją wymagań. Jest takim trochę wirtualnym światem, który poza tym, że porządkuje wymagania, ułatwia ich planowanie. Historyjki użytkownika przechowywane w rejestrze produktu mają różne priorytety”[4].
„W przypadku produkcji nowego produktu rejestr produktu zawiera początkowo cechy niezbędne do zrealizowania wizji właściciela produktu. W przypadku prac nad istniejącym produktem rejestr produktu może zawierać nowe cechy produktu, zmiany cech istniejących, błędy wymagające naprawy, poprawki techniczne itd.” [1].
Sam fakt, że rejestr produktu zmienia się w czasie budzi sporo kontrowersji. Nieznana jest pełna lista wymagań. W klasycznych projektach sytuacja jest identyczna. Z tym wyjątkiem, że w SCRUM nie ma złudzeń co do tego faktu. „Rejestr Produktu powinien zawierać Historyjki Użytkownika wystarczające na pierwsze dwa miesiące rozwoju produktu. Pozostałe wymagania mogą zostać przedstawione w postaci bardziej ogólnych epik”. [3] Osobiście jednak uważam, że rejestr produktu powinien zawierać wiele tygodni lub miesięcy pracy, czyli znacznie więcej, niż można wyprodukować w ciągu pojedynczego, krótkiego sprintu.
To istotne, gdyż trzeba oszacować przynajmniej zgrubnie budżet oraz wymagane zasoby. „Chcąc określić podzbiór najważniejszych elementów rejestru produktu przeznaczonych do wykonania w ciągu nadchodzącego sprintu, właściciel produktu, zespół deweloperski oraz mistrz młyna przeprowadzają planowanie sprintu. „[1] W trakcie Spotkania dot. Planowania Sprintu Właściciel Produktu ustala hierarchię pozycji w rejestrze produktu i opisuje je zespołowi. Do prac w ramach sprintu kierowane są w pierwszej kolejności pozycje rejestru produktu, które mają wysoki priorytet. Następnie zespół określa, które pozycje może wykonać podczas nadchodzącego sprintu. Następnie zespół przenosi pozycje z Product Backloga do rejestru sprintu (Sprint Backloga). W trakcie tej czynności dzieli każdą pozycję Rejestru Produktu na jedno lub kilka zadań Rejestru Sprintu tak, aby zespół mógł skuteczniej dzielić pracę w trakcie Sprintu. Konceptualne, zespół zaczyna od góry zhierarchizowanej listy Product Backloga i zaznacza linię po najniższych pozycjach o wysokim priorytecie, które może wykonać. W praktyce nie jest rzeczą wyjątkową, że zespół wybiera, na przykład, pięć górnych pozycji, a następnie dwie pozycje dolne na liście, ale takie, które mają związek z początkowymi pięcioma.
Pozycje Product Backloga mogą być zadaniami technicznymi lub bardziej skoncentrowane na użytkowniku. „Właściciel produktu współpracuje z wewnętrznymi i zewnętrznymi interesariuszami w celu zebrania i zdefiniowania elementów rejestru produktu. Do jego obowiązków należy zapewnienie odpowiedniej kolejności elementów rejestru (w oparciu o czynniki takie jak wartość, koszt, wiedza i ryzyko) tak, aby elementy o dużej wartości pojawiły się na szczycie rejestru, a pozostałe wylądowały niżej. Rejestr produktu jest artefaktem, który nieustannie ewoluuje. Elementy rejestru mogą być dodawane, usuwane lub modyfikowane przez właściciela produktu wraz ze zmianą uwarunkowań biznesowych, a także w wyniku wzrostu wiedzy (poprzez informacje odkryte w trakcie kolejnych iteracji)na temat produktu wśród członków zespołu scrumowego.„[1]
Rejestr produktu może być zachowany w arkuszu Excela. Arkusz Excela może pokazywać każdą pozycję Rejestru produktu i ogólny priorytet (bardzo wysoki, wysoki, itd.) nadany przez Właściciela Produktu. Osobiście preferuję nadawanie priorytetów metodą MoSCoW. MoSCoW to skrót od:
- M – MUST (musi być): Opisuje pozycję, które musi być spełnione w końcowym, finalnym rozwiązaniu.
- S – SHOULD (powinien być): Reprezentuje pozycję o wysokim priorytecie, która powinna być zawarta w rozwiązaniu, jeżeli jest to możliwe.
- C – COULD (może być): Opisuje pozycję, które jest postrzegane jako pożądane, ale niekonieczne. Zostanie ono zawarte, jeżeli pozwolą na to czas i zasoby.
- W – WON’T (nie będzie): Reprezentuje pozycję, które – za zgodą interesariuszy – nie będzie implementowane w danym wydaniu, ale może być rozpatrzone w przyszłości.
Podstawy Scrum (spis treści)
Scrum – role:
Scrum – produkty:
Scrum – czynności:
- Sprint Planning Meeting – Planowanie Sprintu
- Daily Scrum – Codzienny Scrum
- Sprint Review – Przegląd Sprintu
- Sprint Retrospective – Retrospekcja Sprintu
Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.
