Wyobraź sobie, że wchodzisz na Sprint Review po raz pierwszy jako nowy menedżer. Na ekranie pojawia się Jira z kilkuset wierszami, połowa oznaczona etykietą „do zrobienia”, ćwierć „w trakcie” od co najmniej trzech sprintów, reszta bez priorytetu, bez właściciela, bez daty. Ktoś pyta, co to wszystko jest. Product Owner odpowiada, że to backlog. I w pewnym sensie ma rację, chociaż to trochę tak, jakby powiedzieć, że szuflada pełna starych rachunków i śrubek to „system archiwizacji”.
Słowo backlog przyszło do zarządzania projektami IT z angielskiego, gdzie pierwotnie oznaczało po prostu zaległości, rzeczy, które się nie wyrobiły. Zanim trafiło do Jiry i tablic Kanban, żyło w logistyce i rachunkowości jako coś raczej wstydliwego, sygnał, że firma nie nadąża. Dzisiaj jest artefaktem metodyki. Jak do tego doszło, opisuje artykuł Backlog: słowo, które przyszło z kominka i zostało w Jirze. Warto przejść tę drogę etymologiczną, zanim zacznie się rozmawiać o praktyce.
Co backlog znaczy w Scrumie, a co znaczy w firmie
Oficjalnie, zgodnie ze Scrum Guide Schwabera i Sutherlanda w wersji z 2020 roku, Product Backlog to „emergent, ordered list of what is needed to improve the product”. Trzy słowa robią tu całą robotę: emergent, ordered, product. Nie projekt, nie zadania, nie wishlist sponsora. Produkt. I nie posortowana kolejka, lecz lista z priorytetem, za którą odpowiada jedna konkretna rola, Product Owner.
W praktyce firmy, które nie wdrożyły Scruma w żadnej rozsądnej formie, też mają backlogi. Spreadsheet w Excelu z zakładkami „pomysły”, „do wyceny”, „może kiedyś”. Tablica w Confluence, do której nikt nie zaglądał od sześciu miesięcy. Lista e‑maili od zarządu z prośbami, które developer trzyma w osobnym folderze. To wszystko jest backlogiem w rozumieniu potocznym: zbiór pracy, która czeka na realizację. Jakoś tam posortowany, jakoś tam opisany, raczej niekompletny.
Różnica między tymi dwoma światami jest fundamentalna. W Scrumie backlog ma właściciela z uprawnieniami do decydowania o priorytecie. W typowej firmie bez zdefiniowanej metodyki właścicielstwo backloga jest rozmyte między project managerem, szefem działu IT i dyrektorem, który dosłał wymagania w sobotę wieczorem. Roman Pichler w „Agile Product Management with Scrum” z 2010 roku pisał wprost, że nieuporządkowany backlog bez jednego odpowiedzialnego to przepis na konflikty w sprincie, nie na efektywność.
Trzy rodzaje backloga, z którymi naprawdę masz do czynienia
W Scrumie klasycznym masz Product Backlog i Sprint Backlog. Product Backlog to wszystko, co produkt powinien kiedykolwiek umieć. Sprint Backlog to ten wycinek, który zespół bierze na dwa tygodnie. Prosta hierarchia, piękna w teorii.
Firmy, które urosły albo pracują na kilku produktach jednocześnie, sięgają po framework SAFe, gdzie backlog ma trzy poziomy: Portfolio Backlog (inicjatywy strategiczne, epiki), Program Backlog (funkcjonalności na poziomie pociągu ART) i Team Backlog (user stories, zadania techniczne). Wyobraź sobie organizację 200 osób, która próbuje utrzymać synchronizację między tymi trzema poziomami bez porządnego systemu i bez pełnoetatowego Product Managera na poziomie programu. Kwartalne planowanie PI Planning wygląda wtedy jak próba złożenia IKEA bez instrukcji i z połową śrubek.
Jest też trzeci rodzaj backlogu, o którym nikt nie pisze w podręcznikach: backlog techniczny, czyli dług technologiczny zamieniony w listę. Stare biblioteki do aktualizacji, testy do napisania, architektura do refaktoryzacji. Standish Group w kolejnych edycjach CHAOS Report od lat wskazuje, że zaległości techniczne są jednym z głównych czynników ryzyka projektowego, choć rzadko trafiają do priorytetyzacji na poziomie biznesowym. Sponsor chce nowych funkcji, nie naprawy fundamentów, więc backlog techniczny rośnie cicho, aż pewnego dnia sypie się produkcja i wszyscy są zaskoczeni.
Gdzie backlog pada na twarz
Backlog refinement, czyli regularne przeglądanie i dopracowywanie listy, przez długi czas był w Scrum Guide nazywany grooming. W 2013 roku zmieniono nazwę na refinement, bo w brytyjskim angielskim słowo grooming nabrało złych konotacji. To tylko detal historyczny, ale symptomatyczny: nawet formalny dokument, który definiuje metodykę, ewoluuje pod wpływem kontekstu.
Sama ceremonia, niezależnie jak ją nazwiemy, jest miejscem, gdzie backlog albo zyskuje na wartości, albo staje się archiwum. Zespoły, które pomijają refinement bo „nie ma czasu”, lądują na Sprint Planningu z historiami, których nikt nie rozumie, bez kryteriów akceptacji, z szacunkami wziętymi z sufitu. Mike Cohn w „Agile Estimating and Planning” opisuje mechanizm dokładnie: nieokreślone wymagania na wejściu do sprintu to gwarantowane przekroczenie czasu na wyjściu.
Zanim jednak firma dotrze do pytania, jak prowadzić refinement, musi odpowiedzieć na pytanie bardziej podstawowe: kto w firmie powinien zająć się projektem i czy ta osoba ma realną władzę nad priorytetem backlogu. Bez tego nawet najlepsza Jira jest tylko listą życzeń w ładnym interfejsie.
Pytanie, które warto zostawić bez szybkiej odpowiedzi: jeśli jutro odejdzie Product Owner albo project manager, kto będzie wiedział, dlaczego poszczególne pozycje są w backlogu i dlaczego ułożone są w tej konkretnej kolejności?
Źródła
- Schwaber K., Sutherland J., „Scrum Guide”, scrumguides.org, 2020.
- Pichler R., „Agile Product Management with Scrum”, Addison-Wesley, 2010.
- Cohn M., „Agile Estimating and Planning”, Prentice Hall, 2005.
- Standish Group, „CHAOS Report” (seria raportów cyklicznych).
- Scaled Agile, Inc., „SAFe Framework”, scaledagileframework.com.
Zdjęcie: sadeghshafiee91 / Pixabay
