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. Konceptualnie, 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.
Jakiej klasyfikacji używasz do nadawania priorytetów?
Cały cykl artykułów na temat metodyki Scrum jest pod adresem: https://www.michalwolski.pl/tag/metodyka-scrum/ . Zapraszam do lektury.

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.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close