Backlog: słowo, które przyszło z kominka i zostało w Jirze

cze 16, 2026

Gdzieś w 1680 roku ktoś wrzucił za ruszt duże polano, które miało się palić przez noc i podtrzymywać ogień, gdy reszta drewna się wypalała. Nazywało się back log. Zapas na później. Coś, co leży z tyłu i czeka na swoją kolej. Trzy wieki później to samo słowo trafia do Jiry, Trello i Azure DevOps, gdzie opisuje listę rzeczy do zrobienia, które też czekają na swoją kolej, tyle że zamiast ciepła produkują wykresy burndown.

Etymologia to rzadko przypadek. Backlog w IT brzmi dokładnie jak backlog w XVIII-wiecznej terminologii kupców morskich, gdzie oznaczał zaległe zamówienia, których statek jeszcze nie dostarczył. Zaległość. Rzeczy w kolejce. I to napięcie między “mamy plan” a “nie zdążyliśmy jeszcze” siedzi w tym słowie od początku.

Skąd Scrum wziął ten termin

W styczniu 1986 roku Hirotaka Takeuchi i Ikujiro Nonaka opublikowali w Harvard Business Review artykuł “The New New Product Development Game”. Opisali w nim, jak japońskie firmy takie jak Honda, Canon i Fuji-Xerox organizują pracę nad produktem inaczej niż sekwencyjny model waterfall, który dominował wtedy w przemyśle. Zamiast pałeczki przekazywanej z działu do działu, grają w rugby, gdzie cały zespół przesuwa się razem. Schwaber i Sutherland sięgnęli po tę metaforę i w połowie lat 90. sformalizowali ją w Scrumie. Backlog trafił do oficjalnej terminologii jako jeden z trzech głównych artefaktów frameworku, obok Sprint Backlogu i Inkrement.

W Product Backlogu, zgodnie ze Scrum Guide Schwabera i Sutherlanda, trzyma się wszystko, czego produkt może potrzebować, posortowane według priorytetu. Nie jest to lista zadań do odhaczenia, lecz raczej żywy dokument, który ewoluuje razem z rozumieniem produktu. Każdy element ma opis, kolejność i szacunkową wartość. Brzmi prosto, dopóki lista nie ma 400 pozycji, z których 320 nikt nie dotykał od ośmiu miesięcy.

Dwa różne zwierzęta o tej samej nazwie

Zamieszanie zaczyna się tam, gdzie Product Backlog i Sprint Backlog ludzie traktują jak synonimy. Product Backlog to strategiczny widok na produkt, zarządzany przez Product Ownera, który może sięgać kwartałami do przodu. Sprint Backlog to podzbiór wyciągnięty na konkretny Sprint, najczęściej dwutygodniowy, z planem jak ta praca zostanie wykonana. Wyobraźmy sobie 12-osobowy zespół, który na Sprint Planning wrzuca do Sprintu 40 elementów z Product Backlogu, bo “brzmi realistycznie”. Po dwóch tygodniach skończyło 11. Reszta wraca na Product Backlog. Albo zostaje w Sprint Backlogu i pęcznieje, aż nikt nie wie, który Sprint właściwie trwa.

Roman Pichler w “Agile Product Management with Scrum” z 2010 roku pisał o tym, że Product Backlog ma sens tylko wtedy, gdy Product Owner potrafi powiedzieć, dlaczego dana pozycja jest wyżej niż inna, nie tylko że jest. Priorytet bez uzasadnienia to lista życzeń, nie narzędzie zarządcze. W praktyce większość backlogów, które widziałem w organizacjach po pierwszym roku pracy ze Scrumem, wygląda właśnie jak lista życzeń, tyle że w Jirze.

Backlog poza Scrumem

Termin przeniknął też tam, gdzie Scruma nie ma. Zespoły wsparcia IT prowadzą backlog incydentów. Dział prawny ma backlog umów do przejrzenia. Komitet sterujący w projekcie PRINCE2 dostaje na spotkanie “backlog decyzji eskalowanych”. W tym momencie słowo traci już jakiekolwiek metodologiczne zabarwienie i wraca do swojego pierwotnego znaczenia, czyli po prostu zaległości. Rzeczy, które czekają.

I tu pojawia się pytanie, które warto postawić przed kolejną sesją backlog groomingu, czyli refinementu, jak Scrum Guide woli to nazywać od 2011 roku, kiedy “grooming” okazał się terminem z niefortunnymi konotacjami w języku angielskim. Czy lista, którą właśnie przeglądamy, to narzędzie do podejmowania decyzji, czy tylko dobrze zorganizowany rejestr ambicji, których nikt nie zamierza realizować?

Źródła

  1. Takeuchi H., Nonaka I., “The New New Product Development Game”, Harvard Business Review, styczeń–luty 1986.
  2. Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
  3. Pichler R., “Agile Product Management with Scrum”, Addison-Wesley, 2010.
  4. Cohn M., “Agile Estimating and Planning”, Prentice Hall, 2005.

Zdjęcie: cottonbro studio / Pexels

TL;DR

  • Skąd pochodzi słowo „backlog" i dlaczego jego etymologia wciąż opisuje problem, który mają współczesne zespoły IT.
  • Jak Takeuchi i Nonaka z Harvard Business Review z 1986 roku pośrednio dali Scrumowi jego terminologię.
  • Czym różni się Product Backlog od Sprint Backlogu i dlaczego mylenie ich kończy się zwykle chaosem na Sprint Planning.
  • Jak backlog wyszedł poza Scruma i co się dzieje ze znaczeniem słowa, gdy trafia do PRINCE2 i działów wsparcia IT.
  • Kiedy backlog przestaje być narzędziem decyzyjnym, a staje się rejestrem ambicji.

Zobacz też: