Gdzieś między trzecim sprintem a pierwszym poważnym opóźnieniem zaczyna się pewna charakterystyczna rozmowa. Product Owner otwiera Jirę, scrolluje przez osiemdziesiąt kilka ticketów i mówi: „mamy tu wszystko, czego potrzebujemy”. Zespół kiwa głowami. Trzy tygodnie później połowa tych ticketów nie ma właściciela, jedna czwarta jest nieaktualna, a pięć nowych zadań wpadło bez żadnego opisu i z priorytetem „pilne”. To nie jest patologia. To jest raczej normalny stan backlogu produkcyjnego w większości zespołów IT.
Skąd właściwie pochodzi to słowo
Zanim backlog trafił do Jiry i stal się synonimem „listy rzeczy do zrobienia”, funkcjonował w logistyce jako określenie zaległych zamówień czekających na realizację. W branży IT zadomowił się w okolicach lat 90., kiedy zwinne metody wytwarzania oprogramowania zaczęły szukać prostszego języka niż harmonogramy Gantta. Schwaber i Sutherland, opisując Scrum po raz pierwszy w połowie lat 90., nadali mu konkretną rolę: Product Backlog to uporządkowana lista wszystkiego, co może zwiększyć wartość produktu, a zarządza nim Product Owner. Brzmi prosto. W praktyce ten jeden artefakt potrafi pochłonąć więcej czasu na dyskusje niż samo pisanie kodu.
Szczegóły znajdziesz w oficjalnym Scrum Guide, który Schwaber i Sutherland aktualizowali wielokrotnie, ostatnio w 2020 roku. Wersja z tego roku skróciła definicję backlogu do minimum i dodała pojęcie Product Goal jako kotwicy, wokół której backlog powinien grawitować. To zmiana pozornie kosmetyczna, a w istocie dość fundamentalna: bez jasnego celu backlog jest raczej wysypiskiem pomysłów niż kolejką pracy.
Kiedy backlog produkcyjny staje się problemem
Goldratt w „The Goal” opisał fabrykę, gdzie każdy dział pracował pełną parą, a produkcja i tak się sypała. Wąskie gardło nie leżało tam, gdzie wszyscy myśleli. W świecie IT wąskim gardłem bywa właśnie backlog: nie dlatego, że jest za długi, lecz dlatego, że nikt tak naprawdę nie panuje nad tym, co do niego trafia i w jakiej kolejności to wychodzi. Teoria ograniczeń, którą Goldratt rozwinął w „The Goal” w 1984 roku, mówi wprost, że optymalizowanie elementów systemu poza wąskim gardłem nie poprawia przepustowości całości. Zespół, który zamknął czterdzieści ticketów w sprincie, ale żaden z nich nie był tym, czego faktycznie potrzebował biznes, w pewnym sensie stracił ten sprint.
Wyobraźmy sobie zespół ośmiu deweloperów, który przejął backlog po reorganizacji firmy. Sto dwadzieścia pozycji, część datowana na osiemnaście miesięcy wstecz, opisy w stylu „poprawić UX strony głównej” bez jednego screenshota ani kryterium akceptacji. Pierwsza ceremonia refinementu trwa cztery godziny i kończy się tym, że zespół archiwizuje trzydzieści ticketów jako bezprzedmiotowe. Dopiero wtedy można zacząć rozmawiać o priorytetach. To nie jest scenariusz z gatunku horrorów; to coś, co zdarza się po każdej fuzji, po każdej zmianie Product Ownera i po każdym projekcie, który „chwilowo” przeszedł na Kanbana, bo Scrum był „zbyt formalny”.
Roman Pichler w swojej książce „Strategize” zwraca uwagę na coś, co menedżerowie IT rzadko chcą usłyszeć: backlog jest pochodną strategii produktowej, nie jej substytutem. Kiedy strategia jest mglista, backlog staje się miejscem parkowania wszystkich próśb ze wszystkich działów, bo nikt nie ma argumentów, żeby powiedzieć „nie”. Dobrze brzmiące motto na ścianie sali konferencyjnej to jedno; inną sprawą jest moment, gdy dyrektor sprzedaży wrzuca pilny ticket na dwie godziny przed Sprint Planning i oczekuje, że trafi do najbliższego sprintu.
Backlog produkcji a backlog produktu: subtelna różnica, duże konsekwencje
W produkcji oprogramowania często miesza się dwa pojęcia, które jakoś powinny być rozdzielone. Product Backlog to strategiczna kolejka wartości: co chcemy zbudować i dlaczego. Sprint Backlog to operacyjna lista zadań na dwa tygodnie. Backlog produkcji, rozumiany szerzej, to wszystko, co jest już „w systemie” i czeka na przetworzenie: bugi zgłoszone przez support, długi techniczny, życzenia z działów, inicjatywy z poprzedniego kwartału. Kiedy te trzy warstwy wpadają do jednego narzędzia bez rozróżnienia, chaos jest właściwie gwarantowany.
Standish Group w cyklicznych raportach CHAOS od lat pokazuje, że znacząca część projektów IT nie osiąga zakładanego zakresu w zakładanym czasie. Przyczyny bywają różne, ale nieumiejętne zarządzanie wymaganiami i zmiany zakresu w trakcie projektu niezmiennie trafiają do czołówki. Backlog, który rośnie szybciej niż zespół może go opracowywać, jest właśnie taką zmianą zakresu, tylko rozłożoną w czasie i przez to niewidoczną na żadnym wykresie statusowym.
Więcej o tym, jak backlog funkcjonuje poza kontekstem czysto scrumowym, piszemy w artykule Backlog w firmie: lista życzeń, kolejka robót, czy coś, czym nikt naprawdę nie zarządza. A skąd w ogóle wzięło się to słowo i jak trafiło z palenisk przemysłowych do ekranów z Jirą, opisujemy w osobnym tekście: Backlog: słowo, które przyszło z kominka i zostało w Jirze.
Kto powinien tym zarządzać
Scrum Guide przypisuje Product Backlog Product Ownerowi. W teorii odpowiedzialność jest czysta. W praktyce Product Owner w firmie usługowej obsługuje jednocześnie cztery zespoły i trzy klientów, więc backlog raczej sam się zarządza, czyli nie zarządza się wcale. Refinement odbywa się co dwa tygodnie przez godzinę, bo „mamy mało czasu”, a priorytety ustalane są de facto przez tego, kto głośniej krzyczy albo ma wyższe stanowisko.
Mike Cohn w „Agile Estimating and Planning” opisuje backlog jako żywy dokument, który wymaga regularnej pielęgnacji, a nie jednorazowego ustawienia. To nie jest odkrycie na miarę Kopernika, ale liczba zespołów, które traktują backlog jak tablicę ogłoszeń, sugeruje, że ta prosta obserwacja jakoś nie trafia do praktyki. Pytanie, czy to kwestia narzędzi, procesów, czy po prostu kultury organizacyjnej, w której każdy ma prawo wrzucić coś do kolejki, ale nikt nie ma prawa nic z niej wyrzucić.
Źródła
- Schwaber K., Sutherland J., „Scrum Guide”, scrumguides.org, 2020.
- Goldratt E.M., Cox J., „The Goal”, North River Press, 1984.
- Pichler R., „Strategize: Product Strategy and Product Roadmap Practices for the Digital Age”, Pichler Consulting, 2016.
- Cohn M., „Agile Estimating and Planning”, Prentice Hall, 2005.
- Standish Group, „CHAOS Report” (cykliczne wydania).
Zdjęcie: Daniel Liberty / Unsplash
