Backlog Produktu, rejestr produktu (ang. Product Backlog) jest to lista funkcjonalności ułożonych priorytetowo, opisanych z punktu widzenia użytkownika. Rejestr ten zarządzany jest przez Właściciela Produktu, ale tworzony może być przez wszystkich członków Zespołu Scrumowego.
Pamiętając, że Scrum działa “przyrostowo i iteracyjnie”, nic dziwnego że Backlog Produktu można uzupełniać ciągle w cyklu wytwarzania oprogramowania (dodawać, usuwać funkcjonalności, zmieniać ich priorytety). Z założenia, backlog istnieje tak długo jak produkt. W przeciwieństwie do metodyk tradycyjnych, gdzie wymagania uzgodnione w wydzielonym etapie analizy wymagań biznesowych są ustrukturyzowane i nie podlegają zmianom, w SCRUM zmiany są naturalnym elementem pracy nad funkcjonalnością. Bardzo ważne jednak jest to, że niezależnie od tego, ile zespołów pracuje nad danym projektem, istnieje tylko jeden Backlog Produktu dla jednego produktu.
Backlog Produktu przedstawia zakres prac obejmujący szeroki zakres projektu, znacznie więcej niż jest to możliwe do zrealizowania w jednej iteracji.
Backlog Produktu zbudowany jest jako lista funkcjonalności, tzw. Elementów Backlogu Produktu (ang. Product Backlog Item). SCRUM nie określa postaci, w której muszą być tworzone mimo, iż powinny mieć pewne określone cechy takie jak opis, oszacowaną wielkość czy Kryteria Akceptacji. Jedną z częściej spotykanych postaci zapisu są tak zwane historyjki użytkownika (ang. user stories), które mogą (ale nie jest to wymagane) być zebrane w epiki (ang. epics) czyli rozbudowane funkcjonalności budowane przez kilka historyjek. Historyjki użytkownika są sposobem opisu funkcji, które z punktu widzenia użytkownika są ważne.
Tworzenie Backlog Produktu rozpoczyna się w momencie inicjowania projektu, jako zbiór bardzo ogólnych wymagań funkcjonalnych. Cechą charakterystyczną jest to, że początkowo są to niesprecyzowane wymagania, zawierają tylko ogólne opisy, zarysy funkcjonalności. Doprecyzowanie historyjek lub ich transformacja w epiki i dalszy ich podział na coraz mniejsze, coraz dokładniejsze historyjki lub zadania, następuje w trakcie prac Zespołu Scrumowego.
Ważne jest to, by Zespół by zaznajomiony z Backlog Produktu przed rozpoczęciem spotkania Planowania Sprintu, gdyż brak znajomości kolejnych elementów tego rejestru i konieczność żmudnego omawiania każdego zadania niepotrzebnie wydłuża spotkanie i czyni je mało efektywnym. Omawianie poszczególnych elementów oraz wstępne ich szacowanie powinno odbywać się podczas Refirement Meeting.
Elementy Backlog Produktu powinny być opisane zgodnie z akronimem DEEP używanym przez Romana Pichlera oraz Mike’a Cohn– powinny być odpowiednio doprecyzowane, oszacowane, ciągle powstające i rozwijane oraz uporządkowane pod względem priorytetów.
