Backlog po polsku – zaległości, rejestr czy po prostu lista?

sie 10, 2026

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.

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.

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ć.

“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.

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.

Zrodla

  1. Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
  2. Cohn M., “Agile Estimating and Planning”, Prentice Hall, 2005.
  3. Etymonline.com, haslo “backlog”, etymonline.com.

Zdjęcie: shivam gandhi / Unsplash

TL;DR

  • Skąd pochodzi słowo backlog i co naprawdę znaczy - historia sięga XVII-wiecznych kominków, nie list zadań;
  • Czym różni się Product Backlog od Sprint Backlogu i dlaczego mylenie ich generuje realne awantury;
  • Dlaczego tłumaczenie backlogu jako "zaległości" jest nie tylko nieprecyzyjne, ale aktywnie szkodliwe w komunikacji z zarządem;
  • Jak polskie firmy IT radzą sobie z tym problemem w praktyce - od pełnego anglicyzmu po hybrydy terminologiczne;
  • Jakie pytanie warto zadać sobie zamiast szukać idealnego tłumaczenia.

Zobacz też: