Tradycyjnie w rozwoju oprogramowania dużą rolę odgrywają tak zwane wymagania (ang. requirements). Wymagania to oczekiwane zachowanie aplikacji/produktu. W metodach Agile wymagania dla budowanej aplikacji/systemu gromadzone są na liście, którą nazywa się Backlog Produktu (ang. Product Backlog). Na elementy Backlogu Produktu często mówi się Product Backlog Items – w skrócie PBI (a w popularnym spolszczeniu „ajtemy”).

Backlog Produktu jest zmiennym, „wyłaniającym się” planem rozwoju produktu (ang. emergent plan), tworzonym i zarządzanym przez Product Ownera. Ponieważ działanie zwinne z wykorzystaniem empirycznej kontroli procesu wymaga ciągłego sprawdzenia, czy plan ten jest adekwatny i dostosowania (zmiany zawartości Backlogu lub kolejności elementów), Backlog nigdy nie jest kompletny i jest ciągle zmienny.

Backlog Produktu ma ponadto następujące istotne cechy:

• jest uporządkowany (ang. ordered) – wymagania są ułożone w kolejności realizacji,
• jest adekwatny (ang. relevant) – zawiera wymagania odpowiadające aktualnym potrzebom biznesowym,
• jest przejrzysty (ang. transparent):
  • Backlog jest dla zainteresowanych widoczny i czytelny,
  • osoby korzystające z Backlogu rozumieją wymagania w nim zapisane,
  • każdy widzi w nim tą samą zawartość i kolejność,
• jest wypielęgnowany (ang. refined) – stopień szczegółowości wymagań jest dostosowany do ich pozycji w Backlogu.

Ponadto Backlog może być również oszacowany (ang. estimated) jeśli jest to wymagane i potrzebne do podejmowania dobrych decyzji co do kolejności elementów Backlogu oraz planowania długofalowego. Oszacowanie to może dotyczyć zarówno kosztu jak i spodziewanej wartości wymagań.

Backlog Produktu powinien stanowić jedyne źródło zmian, jakie Developerzy wprowadzają do produktu. Nie oznacza to rzecz jasna, że praca w Sprintach obejmuje wyłącznie realizację elementów Backlogu Produktu, bo przecież niezbędne jest również wdrożenie usprawnień, rozwój narzędzi oraz praktyk developerskich, obsługa produktów (w tym wsparcie użytkowników) czy rozwiązywanie problemów i błędów. Tym niemniej jakiekolwiek zmiany funkcjonalności lub cech produktu, mające wpływ na jego wartość dla użytkowników, powinny wynikać z decyzji Product Ownera wyrażonych zawartością i kolejnością elementów Backlogu Produktu.

Product Owner, porządkując Backlog Produktu (określając kolejność jego elementów), dąży do uzyskania maksymalnej wartości dla użytkowników oraz realizacji aktualnego Celu Produktu. Może zezwolić innym osobom (np. Developerom) na dokonywanie zmian w Backlogu, zachowując przy tym odpowiedzialność (ang. accountability) za skutki ich działań.

W Scrumie Backlog Produktu jest artefaktem i służy do zapewnienia przejrzystości planów rozwoju produktu. Sprawdzenie i dostosowanie Backlogu Produktu może odbyć się w dowolnym momencie, a zdarzeniem, które służy potwierdzeniu adekwatności Backlogu Produktu jest Przegląd Sprintu.

Cel Produktu

Z Backlogiem Produktu wiąże się w Scrumie zobowiązanie (ang. commitment) jakim jest Cel Produktu (ang. Product Goal). Jest to bieżący cel, jaki Product Owner wraz z całym Zespołem Scrum chce osiągnąć poprzez rozwój produktu w kolejnych Sprintach.  To oznacza, że Cele Sprintu kolejnych iteracji wynikać powinny z bieżącego Celu Produktu i być kolejnym krokiem na drodze do jego osiągnięcia.

Backlog Produktu jest ściśle związany z Celem Produktu: wszystkie elementy Backlogu powinny wynikać z bieżącego Celu Produktu. To oznacza, że nie powinno na liście znajdować się rzeczy zbędnych do osiągnięcia tego Celu.

Cel Produktu ma w Scrumie określone cechy:

• W każdym momencie jest tylko jeden Cel Produktu – Zespół Scrum nie może jednocześnie dążyć do osiągnięcia wielu różnych Celów; nowy Cel może być ustanowiony przez Product Ownera dopiero po osiągnięciu aktualnego Celu lub po jego porzuceniu.
• Cel Produktu jest integralnie związany z Backlogiem Produktu, ale nie jest jego elementem, który podejmuje się do realizacji w Sprincie – o tym w jakiej formie Cel zostanie przedstawiony w Backlogu decyduje Product Owner.
• Aby Backlog Produktu był przejrzysty, również Cel Produktu musi być przejrzysty: znany i zrozumiały dla wszystkich zainteresowanych.

Pielęgnacja Backlogu Produktu

Aby możliwe było zaplanowanie kolejnych Sprintów, elementy Backlogu Produktu na jego szczycie muszą być „gotowe” (ang. ready), a więc dostatecznie małe, by dało się je zrealizować w Sprincie, oraz wystarczająco zrozumiałe, by Developerzy potrafili zaplanować ich realizację. W praktyce każde działanie związane z uaktualnieniem Backlogu Produktu jest jego pielęgnacją. Większość działań, jakie wykonuje Product Owner, są jakąś formą pielęgnacji (np. spotkania z interesariuszami czy badanie rynku). Developerzy poświęcają na udział w tym procesie zwykle dużo mniej czasu w Sprincie (dobrym punktem odniesienia jest ok. 10% dostępnego czasu iteracji).

Pielęgnacja obejmuje wiele działań, w tym:

• edycję elementów Backlogu Produktu,
• ich doprecyzowanie,
• szacowanie wartości i wielkości (pracochłonności, złożoności itd.),
• definiowanie kryteriów akceptacji (jeśli ta opcjonalna praktyka jest używana),
• porządkowanie elementów (ustalenie ich kolejności),
• dekompozycję na mniejsze elementy tak, by stały się „gotowe”.

Pielęgnacja nie jest zdarzeniem w Scrumie z dwóch powodów:

• Jest to proces, obejmujący zarówno spotkania, jak i pracę odbywającą się pomiędzy spotkaniami (np. testy, tworzenie prototypów, konsultacje z ekspertami itd.).
• To w jakiej formie, kto i kiedy weźmie udział w Pielęgnacji, zależy od charakteru produktu, bieżącego stanu Backlogu, sposobu działania organizacji – a same spotkania są opcjonalne i powinny być robione wtedy, jeśli Zespół Scrum uzna, że są potrzebne.

W procesie Pielęgnacji uczestniczy cały Zespól Scrum (choć nie wszyscy w każdym momencie), możliwe jest również zaproszenie ekspertów, w tym interesariuszy i użytkowników produktu.

Pielęgnacja dotyczy elementów Backogu Produktu, które nie zostały jeszcze podjęte do realizacji w Sprincie, co nie oznacza, że dalsze analizy (już w czasie iteracji) i dyskusje nie mogą się odbywać. Są one wtedy częścią procesu budowania produktu i nie stanowią Pielęgnacji Backlogu Produktu. Natomiast warto pamiętać, że Pielęgnacja nie ma doprowadzić do pewności odnośnie tego, co przyniesie wartość i jak tę wartość wytworzyć. Tak postawiony cel nie jest możliwy do osiągnięcia w prawdziwie zmiennym środowisku, a gdyby był, użycie Scruma i empiryczna kontrola procesu byłaby zbędna.

Celem Pielęgnacji jest przygotowanie Zespołu Scrum do planowania kolejnego Sprintu tak, by członkowie Zespołu wiedzieli co i dlaczego znajduje się na szczycie Backlogu. Dzięki tej wiedzy możliwe jest skuteczne ustalenie Celu Sprintu i stworzenie prognozy tego, co trzeba zrobić, aby taki Cel osiągnąć.

Pielęgnacja nie powinna być również używana aby wstępnie zaplanować przyszłe Sprinty, podejmując już decyzje związane z tym, jak elementy Backlogu Produktu będą realizowane. O ile dyskusja o architekturze może być konieczna, bo wpływa na koszt realizacji wymagań, a różne rozwiązania mogą generować specyficzne ograniczenia i zależności, Zespół Scrumowy powinien ustalać sposób realizacji wymagań dopiero na Planowaniu Sprintu.