W jednej sali konferencyjnej siedzą analitycy giełdowi i rozmawiają o backlogu Asseco Poland, który na 2025 rok wyniósł 13,5 mld zł w portfelu zamówień. W drugiej sali, piętro wyżej, Product Owner tłumaczy właśnie swojemu zespołowi, dlaczego sprint backlog ma 47 pozycji i nikt z nich nie skończy się w tym tygodniu. Oboje używają tego samego słowa. Oboje mają rację. I jakoś nigdy nie rozmawiają ze sobą o tym, że mówią o zupełnie różnych rzeczach.
Skąd w ogóle wzięło się to słowo
Backlog to słowo angielskie, dosłownie oznaczające nagromadzone zaległości, pracę, której jeszcze nie zrobiono, a którą ktoś już obiecał zrobić. W kontekście finansowym i biznesowym funkcjonuje od dziesięcioleci jako portfel zamówień, czyli wartość kontraktów podpisanych, lecz niezrealizowanych. Spółki budowlane, produkcyjne i technologiczne raportują go regularnie inwestorom, bo to jeden z lepszych wskaźników wyprzedzających przyszłe przychody. Torpol podawał rekordowy backlog na poziomie 4,48 mld zł, Synektik ogłaszał wzrost ponad dziesięciokrotny do 114 mln zł. Dla analityka to liczba, która mówi, ile roboty firma ma zapewnionej na kolejne kwartały.
Mniej więcej w tym samym czasie, gdy te raporty trafiały do inwestorów, w świecie zwinnych metodyk słowo backlog zrobiło zupełnie inną karierę. Ken Schwaber i Jeff Sutherland w kolejnych edycjach Scrum Guide definiowali Product Backlog jako emergent, ordered list, czyli dynamiczną, uporządkowaną listę wszystkiego, co potrzebne do rozwijania produktu. W wersji z 2020 roku ta definicja jest bodaj najkrótsza i najostrzejsza ze wszystkich: pojedyncze źródło pracy dla Scrum Teamu. Żadnych zaległości, żadnych obietnic, tylko lista możliwości uszeregowanych według wartości.
Dwa znaczenia, dwa problemy
Finansowy backlog spółki bywa kłopotliwy z zupełnie innych powodów niż backlog produktu w Scrumie. Kiedy portfel zamówień rośnie, wszyscy się cieszą, ale nikt nie pyta od razu, czy firma ma zdolności przerobowe, żeby to wszystko zrealizować w terminie. ZUE chwalił się backlogiem wartości 3,6 mld zł i jednocześnie szacował możliwości przerobu na 2 mld zł rocznie, co oznacza, że przy takim tempie roboty wystarczy na ponad półtora roku. Dla inwestora to sygnał stabilności. Dla project managera wewnątrz tej firmy to już raczej pytanie, ile zespołów trzeba rozbudować albo ile podwykonawców zatrudnić, zanim terminy zaczną się sypać.
Z backlogiem produktu w sensie scrumowym problem jest inny i w pewnym sensie odwrotny. Tutaj zagrożenie nie jest w tym, że lista jest za długa, żeby ją obsłużyć, choć to też się zdarza. Zagrożenie polega na tym, że lista istnieje, jest w Jirze, ma 200 pozycji, ale nikt tak naprawdę nie wie, które z nich mają jeszcze sens. Cohn w Agile Estimating and Planning pisał o tym, jak szacowanie bez kontekstu priorytetów staje się rytuałem bez wartości. Backlog, który przez pół roku rósł bez regularnego przeglądania, to trochę jak szafa z rzeczami, których już nie nosisz: technicznie wszystko tam jest, ale znalezienie czegoś użytecznego zajmuje tyle czasu, że szkoda zachodu. Dlatego backlog grooming bywa ceremonią, która w połowie zespołów istnieje tylko z nazwy, bo nikt nie chce poświęcać popołudnia na porządkowanie listy, która i tak następnego dnia znów urośnie.
Gdzie te dwa światy się spotykają i dlaczego to jest bardziej skomplikowane
W spółkach technologicznych, które jednocześnie są firmami produktowymi i dostawcami kontraktowymi, oba backlogowe światy nakładają się na siebie w sposób, który potrafi przyprawić o ból głowy nawet doświadczonego CIO. Zarząd patrzy na backlog w sensie portfela zamówień i ocenia kondycję firmy. Zespoły deweloperskie zarządzają backlogiem produktu w Jirze, gdzie każda historia użytkownika ma swój story point i właściciela. Między tymi dwiema warstwami rzadko istnieje przejrzyste przełożenie, jak konkretna pozycja z listy życzeń produktowych przekłada się na wartość konkretnego kontraktu, który zaraportowano inwestorom.
Dobrze zarządzane firmy próbują tę lukę zamknąć przez Product Roadmapę i backlog produktu, który naprawdę rządzi projektem, a nie tylko zajmuje miejsce w narzędziu. Roman Pichler w Strategize przekonuje, że Product Goal to właśnie ten brakujący pomost, strategiczny punkt odniesienia, który nadaje sens kolejności pozycji na liście. Bez niego backlog produktu i backlog biznesowy spółki to dwa monologi prowadzone w tym samym języku, ale w różnych salach konferencyjnych.
Pytanie, które warto sobie zadać przy następnym raporcie kwartalnym albo przy następnym Sprint Review, brzmi mniej więcej tak: czy ludzie, którzy dziś chwalą się rosnącym portfelem zamówień, i ci, którzy właśnie zamknęli sprint z dziesięcioma story pointami, rozumieją, że grają w tej samej grze?
Źródła
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Cohn M., “Agile Estimating and Planning”, Prentice Hall, 2005.
- Pichler R., “Strategize”, Pichler Consulting, 2016.
- Asseco Group, komunikaty prasowe dotyczące backlogu zamówień na 2025 rok, asseco.com.
- Standish Group, CHAOS Report (cykliczne badania nad skutecznością projektów IT).
Zdjęcie: Arina Dmitrieva / Pexels
