W Scrumie mamy backlog produktu, co jest specyficznym terminem używanym w tej metodologii. W Agile możemy używać ogólniejszego terminu – po prostu backlog. W backlogu znajdują się wymagania, które określają zakres w środowisku Agile. Tworząc backlog, definiujemy faktyczny zakres projektu. Podczas jego tworzenia bierzemy pod uwagę MVP – minimalnie opłacalny produkt. To oznacza elementy, które są wystarczające, aby klient mógł zacząć korzystać z produktu.
Po stworzeniu MVP klient może rozpocząć korzystanie z produktu i udzielić nam informacji zwrotnej. Na przykład, przy tworzeniu komercyjnej strony internetowej, na początku możemy stworzyć stronę sprzedaży i stronę płatności. Klient może od razu zacząć korzystać z witryny, a my możemy dodać inne strony, jak blogi i „o nas” później.
Wiemy, że właściciel produktu odpowiada za backlog i współpracuje z zespołem, aby go tworzyć i aktualizować. W backlogu znajdują się wymagania, które są priorytetyzowane pod kątem wartości biznesowej i ryzyka. Wymagania o wyższym priorytecie umieszczane są na początku, a te o niższym priorytecie później. Ponieważ backlog jest priorytetyzowany z uwzględnieniem ryzyka, można go nazwać backlogiem skorygowanym o ryzyko. Wymagania w backlogu mają postać historii, na przykład jako administrator, chcę zobaczyć wszystkich klientów i ich adresy e-mail w formie listy, aby móc się z nimi łatwo skontaktować.
To, czego nauczyliśmy się na poprzednich wykładach, to między innymi różnice między funkcją a historią. Funkcja to funkcjonalność oferowana przez produkt. Niektóre funkcje mogą być ukończone jedną historią, a inne mogą wymagać więcej niż jednej historii, aby zostać zrealizowane. Omówmy teraz backlog bardziej szczegółowo.
Na początku projektu określane są znane wymagania. Nie określamy wszystkich wymagań na początku, co jest logiczne w niepewnym środowisku. Jeśli wiemy, co robić w pierwszych iteracjach, mamy wystarczająco historii, aby rozpocząć projekt.
Historia powinna zajmować od jednego dnia do jednego tygodnia. Jeśli zajmuje dłużej, jest to prawdopodobnie epik. Epik to duży zakres pracy, który nie może być dostarczony w jednej iteracji. Niektóre epiki składają się z pojedynczej frazy, jak „stworzenie przyjaznej strony sprzedaży”.
Epiki nie są złe, a wręcz przeciwnie, pomagają tworzyć historie użytkownika łatwiej. Produkt właściciel tworzy mapę drogową produktu i dzieli się nią z zespołem. Mapa drogowa produktu pomaga zrozumieć ryzyka i sprawdzić wykonalność projektu. Pomaga zespołowi zobaczyć szerszą perspektywę i dostosować priorytety i wymagania.
Tworzenie historii użytkownika odbywa się przy pomocy technik takich jak mapowanie wpływu, które prowadzi właściciel produktu. Mapowanie wpływu pomaga zespołowi zrozumieć wymagania i określić cel, który chce osiągnąć. Technika ta obejmuje ustalenie aktorów, którzy przyczyniają się do realizacji celu, a także sposobu ich działania i potrzeb.
Backlog powinien mieć definicję „zrobione” – checklistę rzeczy, które muszą zostać ukończone, by uznać zadanie za zakończone. Kryteria akceptacji są określane dla każdej historii i są bardziej specyficzne niż ogólna definicja „zrobione”. Określają one dokładne wymagania dotyczące wykonania historii i pomagają zespołowi zrozumieć, czy cel danej historii został spełniony.
Podział i priorytetyzacja historii mogą wykorzystywać metodę CD3, która określa, które zadania mają większy priorytet, biorąc pod uwagę koszt opóźnienia podzielony przez czas trwania (cost of delay divided by duration). Warto jednak uwzględnić inne ograniczenia i ryzyka przy ostatecznym podejmowaniu decyzji dotyczących priorytetów.
Backlog to dokument dynamiczny, który nigdy nie jest ukończony i jest regularnie aktualizowany, aby był gotowy na kolejne iteracje. Nazywa się to procesem refinacji backlogu.
Dla środowisk flow-based backlog może być aktualizowany przed rozpoczęciem kolejnej historii. Jeśli mamy iteracyjny Agile, można spotkania robić w środku iteracji, a czas ich trwania powinien wynosić około godziny. Jeśli spotkania trwają dłużej, może to wskazywać na braki doświadczenia w zespole.