Backlog – definicja robocza zanim przejdziemy do problemu
Zanim rozłożymy na części spór o tłumaczenie, ustalmy punkt wyjścia. Backlog to uporządkowana, priorytetyzowana lista wymagań i zadań do realizacji, z której zespół czerpie pracę. W Scrumie jest to jedyne źródło pracy podejmowanej przez zespół, a nie boczny notatnik na luźne pomysły.
Kluczowe jest to, że elementy w backlogu są ułożone w kolejności. To, co na górze, robisz najbliżej; to, co na dole, może poczekać albo w ogóle nigdy nie trafi do realizacji. Backlog żyje – dochodzą nowe pozycje, stare wypadają, priorytety się przetasowują wraz z tym, czego dowiadujesz się o produkcie i rynku. Reszta artykułu dotyczy tego, dlaczego to proste narzędzie tak trudno nazwać po polsku bez nieporozumień.
Gdzieś między rokiem 2005 a 2010, kiedy Scrum zaczął podbijać polskie firmy IT, pojawił się problem, który większość zespołów po cichu zamiotła pod dywan. Jak przetłumaczyć “backlog”? Zaległości? Rejestr wymagań? Lista rzeczy do zrobienia? Każde z tych tłumaczeń jest trochę prawdziwe i jednocześnie trochę pudłuje, więc środowisko wybrało najwygodniejsze wyjście – zostawiło angielski termin i udało, że nie ma problemu.
Szkoda, że problem jest. I to dość konkretny.
Skąd pochodzi słowo, które wszyscy odmieniają przez przypadki
Słowo “backlog” ma rodowód, który w kontekście IT brzmi niemal absurdalnie. W latach 80. XVII wieku oznaczało dosłownie kłodę drewna układaną z tyłu kominka – tę dużą, ciężką, która pali się powoli i podtrzymuje ogień przez noc. Przenośne znaczenie pojawiło się dopiero w latach 80. XIX wieku i oznaczało rezerwy nagromadzone na przyszłość. Nie zaległości, nie opóźnienia. Rezerwy. Coś celowo odłożonego na później, bo może się przydać.
To rozróżnienie gdzieś po drodze zginęło. Kiedy Ken Schwaber i Jeff Sutherland pisali Scrum Guide (którego aktualna wersja pochodzi z 2020 roku i jest dostępna na scrumguides.org), Product Backlog zdefiniowali jako “emergent, ordered list of what is needed to improve the product” – wyłaniającą się, uporządkowaną listę tego, co potrzebne do ulepszenia produktu. Ani słowa o zaległościach. A mimo to polskie środowisko IT nagminnie mówi “mamy zaległy backlog”, co brzmi jak “mamy zaległy zapas na później”, czyli niemal bezsensownie.
Backlog w IT – czym jest i czym nie jest
Najwięcej nieporozumień bierze się z tego, że backlog myli się z rzeczami, którymi nie jest. Zdrowy backlog różni się od zwykłej listy zadań czterema cechami: ma właściciela, jest priorytetyzowany, ewoluuje w czasie i służy jako jedyne źródło prawdy o planowanej pracy. Zwykła lista “do zrobienia” żadnej z tych cech nie ma – to płaski zbiór pozycji bez kolejności i bez osoby, która za nią odpowiada.
Dobrze zbudowany backlog produktu opisuje angielski akronim DEEP:
- Detailed appropriately – elementy blisko realizacji są opisane szczegółowo, odległe pozostają ogólne;
- Estimated – pozycje mają oszacowanie nakładu, choćby zgrubne;
- Emergent – lista się zmienia, dochodzą i wypadają elementy;
- Prioritized – wszystko jest ułożone według ważności, a nie kolejności wpisywania.
Backlog to także nie lista życzeń, do której każdy dopisuje pomysły bez kontroli. Więcej o tym, jak DEEP działa w praktyce, znajdziesz w opracowaniu Mountain Goat Software: Make the Product Backlog DEEP.
Trzy słowa, trzy różne rzeczy – i to nie jest drobnostka
W Scrumie słowo backlog pojawia się w co najmniej dwóch kontekstach, które mają zasadniczo różny charakter. Product Backlog to lista prowadzona przez Product Ownera, obejmująca wszystkie wymagania, pomysły i poprawki dla całego produktu – żyje przez cały czas trwania projektu i nieustannie się zmienia. Sprint Backlog to coś innego: podzbiór wybrany na konkretny sprint, uzupełniony o plan działania, i przez te dwa tygodnie zasadniczo zamrożony. Scrum Guide mówi wprost, że Sprint Backlog należy do Deweloperów, nie do Product Ownera.
Zestawienie obu artefaktów pokazuje, dlaczego zamienne używanie słowa “backlog” prowadzi na manowce:
- właściciel – Product Backlog należy do Product Ownera, Sprint Backlog do Deweloperów;
- zakres – Product Backlog obejmuje cały produkt, Sprint Backlog jeden sprint;
- zmienność – Product Backlog jest żywy i stale rozwijany, Sprint Backlog na czas sprintu pozostaje w zasadzie zamrożony;
- zawartość – Sprint Backlog dokłada do wybranych elementów cel sprintu i plan dostarczenia inkrementu.
Wyobraź sobie teraz zebranie, na którym ktoś mówi “musimy omówić backlog”. Połowa sali myśli o Product Backlogu i priorytetyzacji na kwartał, druga połowa myśli o zadaniach na bieżący sprint. Nikt nie pyta o doprecyzowanie, bo wszyscy zakładają, że rozumieją to samo słowo tak samo. To jeden z tych momentów, gdzie niejednoznaczna terminologia wygeneruje awanturę dwa tygodnie później, przy Sprint Review, kiedy okaże się, że zespół zrobił nie to, co zamawiający miał na myśli.
Jeśli chcesz zobaczyć, jak wygląda backlog produktu w praktyce – z konkretnymi przykładami elementów i strukturą, warto przyjrzeć się temu zanim ta niejednoznaczność zacznie kosztować. Oficjalne definicje obu artefaktów znajdziesz w The 2020 Scrum Guide – oficjalnej definicji Product Backlog i Sprint Backlog.
Backlog w projektach IT – zastosowanie poza Scrumem
Backlog nie jest wyłącznie elementem Scruma. Pojęcie funkcjonuje w szerszym zarządzaniu projektami IT i pojawia się wszędzie tam, gdzie praca płynie z jednej uporządkowanej listy.
W Kanbanie backlog pełni rolę kolumny wejściowej. Zadania czekają w niej na pobranie zgodnie z zasadą pull i limitami pracy w toku (WIP), a zespół sięga po nową pozycję dopiero wtedy, gdy zwolni się miejsce. Backlog spotkasz też w podejściach hybrydowych i w Personal Kanbanie, gdzie pojedyncza osoba porządkuje własne zadania. Za każdym razem mechanizm jest ten sam: jedna lista, ustalona kolejność, praca pobierana z góry.
Ta uniwersalność ma praktyczną konsekwencję. Jeśli twoja firma nie pracuje w czystym Scrumie, backlog nadal jest sensownym narzędziem – pod warunkiem, że zachowasz priorytetyzację i wskażesz właściciela listy. Bez tych dwóch rzeczy backlog zamienia się w archiwum pomysłów, którym nikt nie zarządza. Wskazówki dotyczące budowania i porządkowania takiej listy znajdziesz w opracowaniu Atlassian: Product backlog – wskazówki dotyczące tworzenia i priorytetyzacji.
“Zaległości” to nie jest niewinne tłumaczenie
Słowo “zaległości” niesie ze sobą ładunek emocjonalny, którego backlog nie powinien mieć. Zaległości to coś, czego nie zdążyłeś zrobić i powinieneś się wstydzić. Tymczasem Product Backlog pełen nierozwiniętych pomysłów i niepriorytetowych wymagań to nie dowód na nieudolność zespołu – to zdrowy stan rzeczy. Mike Cohn w “Agile Estimating and Planning” opisuje backlog jako narzędzie adaptacji, nie jako listę win i strat.
Problem z tłumaczeniem “zaległości” ujawnia się najdotkliwiej podczas rozmów z zarządem firm, które właśnie wdrożyły Scrum. Wyobraź sobie scenę, która pewnie zdarzyła się w dziesiątkach polskich korporacji: Project Manager pokazuje prezesowi Jirę i mówi “mamy 200 zaległości”. Prezes słyszy, że zespół ma 200 rzeczy, z którymi nie dał rady. Następuje eskalacja. Ktoś żąda wyjaśnień. Trzy godziny spotkań później okazuje się, że te 200 pozycji to po prostu lista planowanych funkcjonalności na następne pół roku – czyli dokładnie to, co powinno tam być.
Jak polskie firmy sobie z tym radzą
Praktyka jest raczej niejednorodna. Część zespołów po prostu mówi “backlog” i tyle – termin funkcjonuje jako zapożyczenie, tak jak “sprint”, “story” czy “stakeholder”. To podejście ma swoje zalety, bo nie generuje dodatkowego zamieszania terminologicznego, i swoje wady, bo zamknięte jest na rozmowę z każdym, kto nie siedzi w IT.
Inne firmy próbują konsekwentnie mówić “rejestr produktu” albo “lista wymagań”, co z kolei tworzy własne problemy – bo “lista wymagań” ma historię w metodykach kaskadowych i przychodzi z innym zestawem skojarzeń. PRINCE2 też używa rejestru – Risk Register, Issue Register – więc “rejestr” jako tłumaczenie nie jest pozbawione sensu, ale wymaga każdorazowego dookreślenia, o jakim rejestrze mówimy.
Najuczciwszym rozwiązaniem, jakie spotkałem w praktyce, jest podejście hybrydowe: w komunikacji wewnątrz zespołu Scrum mówi się “backlog”, a w raportach dla zarządu tłumaczy się to jako “lista priorytetów produktu” albo “plan wymagań” – z wyraźnym wyjaśnieniem, że długa lista to nie patologia, a planowanie. Brzmi jak drobnostka. W firmach, gdzie projekt musi raportować do komitetu sterującego co sześć tygodni, ta drobnostka potrafi zaoszczędzić dwie godziny nieporozumień na każdym spotkaniu.
Terminologia backlogu w praktyce – kto słyszy co i jak temu zaradzić
Diagnoza problemu nie zamyka sprawy. Jeśli chcesz, żeby w twojej firmie słowo “backlog” nie wywoływało dwóch różnych obrazów w dwóch głowach, potrzebujesz konwencji. Nie chodzi o narzucenie jednego tłumaczenia wszystkim, tylko o świadome dobranie określenia do odbiorcy.
Sprawdza się prosty podział według kontekstu komunikacji:
- wewnątrz zespołu deweloperskiego – zostaw “backlog”, bo to język, który wszyscy tam rozumieją;
- w raporcie dla zarządu – mów “lista priorytetów produktu” i dodaj, że długa lista to plan, nie opóźnienie;
- w rozmowie z nowym klientem – użyj “planu wymagań” lub “listy funkcjonalności” i wyjaśnij pojęcie przy pierwszym użyciu.
Drugim krokiem jest spisanie mini-słowniczka i wklejenie go na początek dokumentacji projektu albo do opisu przestrzeni w Jirze. Nie musi być długi. Wystarczą trzy do pięciu pozycji, które ucinają najczęstsze nieporozumienia:
- backlog produktu – lista priorytetów całego produktu, prowadzona przez Product Ownera;
- sprint backlog – plan pracy zespołu na bieżący sprint;
- refinement – regularne porządkowanie i doprecyzowywanie listy;
- element backlogu – pojedyncza pozycja do realizacji, np. funkcja lub poprawka.
Gdy raportujesz do biznesu, gotowe zdanie oszczędza tłumaczeń w kółko. Przykład, który możesz skopiować: “Na liście priorytetów produktu mamy obecnie 200 zaplanowanych funkcjonalności na najbliższe pół roku; to nasz plan rozwoju, nie zaległości.” Taka jedna linijka zamyka temat, zanim ktokolwiek zdąży się zaniepokoić liczbą.
- ustal, kto jest odbiorcą, i dobierz określenie do jego języka;
- spisz słowniczek 3–5 terminów i umieść go w widocznym miejscu dokumentacji;
- przygotuj jedno zdanie raportujące, które odróżnia plan od zaległości;
- stosuj wybraną konwencję konsekwentnie we wszystkich dokumentach i narzędziach.
Pytanie, które zostaje bez odpowiedzi
Polskie środowisko IT od lat prowadzi tę samą rozmowę i jakoś nie dochodzi do konsensusu. Może dlatego, że problem jest realny tylko w połowie przypadków – w jednojęzycznych, zamkniętych zespołach deweloperskich backlog po angielsku funkcjonuje bez tarcia. Tarcie pojawia się na granicy, tam gdzie IT spotyka biznes, gdzie Product Owner tłumaczy priorytety dyrektorowi finansowemu, gdzie Scrum Master próbuje wytłumaczyć metodykę nowemu klientowi. I właśnie na tej granicy język ma znaczenie – nie jako estetyka, ale jako narzędzie. Pytanie, które warto sobie zadać, to nie “jak przetłumaczyć backlog”, ale “kto w mojej firmie nie rozumie, co to jest, i jakie decyzje przez to podejmuje źle”.
A jeśli chcesz sprawdzić, jak backlog grooming wygląda w zespołach, które traktują go poważnie, to jest tam kilka obserwacji, które mogą zmienić sposób, w jaki prowadzisz refinement.
Najczęstsze pytania
Co to jest backlog?
Backlog to uporządkowana, priorytetyzowana lista wymagań i zadań do realizacji, z której zespół czerpie pracę. Według Scrum Guide 2020 Product Backlog jest jedynym źródłem pracy podejmowanej przez zespół, a nie wykazem nieukończonych zadań. To aktywne narzędzie planowania, nie lista zaległości.
Co to znaczy backlog po polsku?
Backlog nie ma jednoznacznego polskiego odpowiednika. “Zaległości” sugerują pasywny stan i coś, czego nie zdążono zrobić. “Rejestr” podkreśla funkcję ewidencyjną. “Lista priorytetów” oddaje dynamikę, ale gubi część znaczenia. Żadne z tych tłumaczeń nie ujmuje w pełni backlogu jako żywego artefaktu, który ma właściciela i ewoluuje przez cały cykl życia produktu.
Czym różni się Product Backlog od Sprint Backlogu?
Product Backlog należy do Product Ownera, obejmuje cały produkt i jest stale rozwijany. Sprint Backlog należy do Deweloperów, obejmuje jeden sprint i na czas jego trwania pozostaje zasadniczo zamrożony. Sprint Backlog to podzbiór elementów wybranych z Product Backlogu, uzupełniony o cel sprintu i plan realizacji.
Czy backlog to to samo co lista zadań?
Nie. Backlog jest priorytetyzowany, ma właściciela, ewoluuje w czasie i służy jako jedyne źródło prawdy o planowanej pracy. Zwykła lista zadań to płaski zbiór pozycji bez ustalonej kolejności i bez osoby, która za nią odpowiada.
Ile pozycji powinien mieć backlog?
Scrum Guide nie narzuca sztywnej liczby. Zdrowy backlog ma tyle pozycji, ile zespół jest w stanie sensownie priorytetyzować, zwykle kilkadziesiąt aktywnych elementów. Pozycje bliskie realizacji powinny być opisane szczegółowo, a odległe mogą pozostać ogólne. Praktyczna zasada mówi o co najmniej dwóch sprintach w pełni doprecyzowanych elementów na górze listy.
Zrodla
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Cohn M., “Agile Estimating and Planning”, Prentice Hall, 2005.
- Etymonline.com, haslo “backlog”, etymonline.com.
Zdjęcie: shivam gandhi / Unsplash
