Pracując z zespołami na szkoleniach Professional Scrum Master i Professional Scrum Product Owner, regularnie obserwuję fascynujące zjawisko. Kiedy proszę uczestników o stworzenie zarysu Product Backlogu dla wymyślonego produktu, w 80% przypadków otrzymuję coś zupełnie innego. Zamiast uporządkowanej listy elementów dostarczających wartość użytkownikom, widzę harmonogramy projektu, struktury podziału pracy czy rejestry wymagań.
To pokazuje, jak głęboko zakorzenione są nasze nawyki myślenia projektowego. I choć jest to zrozumiałe, może być destrukcyjne dla prawdziwego Scruma.
Product Backlog to nie harmonogram projektu
Harmonogram projektu odpowiada na pytanie “kiedy?”. Pokazuje sekwencję zadań w czasie, zależności między nimi i kamienie milowe. Ma jasny początek i koniec, określone fazy realizacji.
Product Backlog odpowiada na zupełnie inne pytanie: “co przyniesie największą wartość użytkownikom?”.
Na jednym ze szkoleń w Warszawie zespół tworzący aplikację do zamawiania jedzenia rozpoczął od takiej listy:
Sprint 1 (2 tygodnie): Analiza wymagań, projektowanie mockupów
Sprint 2 (2 tygodnie): Konfiguracja środowiska, setup bazy danych
Sprint 3 (2 tygodnie): Implementacja logowania użytkownika
Sprint 4 (2 tygodnie): Implementacja katalogu restauracji
Sprint 5 (2 tygodnie): Implementacja koszyka zakupów
Sprint 6 (2 tygodnie): Integracja z systemem płatności
Sprint 7 (2 tygodnie): Testy końcowe i deployment
Brzmi znajomo? To klasyczny harmonogram z przypisanymi datami ukończenia realizacji, ale nie Product Backlog.
Product Backlog nie ma dat zakończenia etapów. Produkt ewoluuje tak długo, jak długo jest używany. Nie ma faz – jest ciągłe dostarczanie wartości w przyrostach. Prawidłowy Product Backlog dla tej samej aplikacji zaczynałby się od User Story w stylu: “Jako głodny użytkownik chcę móc zamówić pizzę online, żeby nie musieć dzwonić” czy “Jako właściciel restauracji chcę otrzymywać zamówienia elektronicznie, żeby zmniejszyć błędy w przyjmowaniu zamówień telefonicznych”.
Product Backlog to nie Work Breakdown Structure (WBS)
WBS rozkłada projekt na mniejsze, łatwiejsze do zarządzania zadania i działania. Koncentruje się na pracy potrzebnej do zbudowania produktu. Jest hierarchiczny i kompletny – pokazuje wszystkie zadania, jakie trzeba wykonać.
Pamiętam zespół ze szkolenia w Krakowie, który dla aplikacji bankowej stworzył coś takiego:
- Analiza
1.1. Przeprowadzenie wywiadów z użytkownikami
1.2. Analiza konkurencji
1.3. Dokumentacja wymagań funkcjonalnych
1.4. Dokumentacja wymagań niefunkcjonalnych - Projektowanie
2.1. Projekt interfejsu użytkownika
2.2. Projekt architektury systemu
2.3. Projekt bazy danych
2.4. Przegląd projektów - Implementacja
3.1. Przygotowanie środowiska deweloperskiego
3.2. Implementacja warstwy danych
3.3. Implementacja logiki biznesowej
3.4. Implementacja interfejsu użytkownika
3.5. Testy jednostkowe - Testy
4.1. Przygotowanie danych testowych
4.2. Testy integracyjne
4.3. Testy akceptacyjne
4.4. Testy wydajnościowe
To idealny WBS, ale katastrofalny Product Backlog. Skupia się na zadaniach do wykonania, nie na wartości dla użytkownika.
Product Backlog nie jest kompletny i nie musi taki być. Ewoluuje wraz ze zrozumieniem produktu. Zawiera elementy opisujące wartość, nie zadania implementacyjne.
Product Backlog to nie architektura systemu
Architektura systemu definiuje strukturę techniczną, komponenty, ich relacje i zasady projektowania. Odpowiada na pytanie “jak system będzie zbudowany?”.
Na innym szkoleniu miałem zespół, który dla aplikacji bankowej stworzył taki Product Backlog:
- Frontend
1.1. Logowanie użytkownika
1.2. Dashboard główny
1.3. Moduł przelewów - Backend
2.1. Autoryzacja
2.2. Walidacja
2.3. Logowanie operacji - Struktura danych
3.1. Projekt bazy danych
3.2. Procedury składowane
To komponenty architektury, nie elementy Product Backlogu.
Często widzę na szkoleniach podobne próby tworzenia Backlogu w stylu: “Moduł uwierzytelnienia”, “API Gateway”, “Microservice użytkowników”, “Load balancer”. Product Backlog koncentruje się na efektach dla użytkownika, nie na architekturze. Jeśli architektura pojawia się w Backlogu, powinna być wyrażona przez wartość biznesową.
Product Backlog to nie rejestr wymagań
Rejestr wymagań to kompletna dokumentacja tego, co system ma robić. Opisuje funkcje, ograniczenia, interfejsy. Jest szczegółowy, formalny i często niezmienny po zatwierdzeniu.
Na szkoleniu w Poznaniu widziałem prawdziwy “Product Backlog”, który wyglądał jak typowy rejestr wymagań:
- REQ-001: System musi zapewniać uwierzytelnienie dwuskładnikowe zgodne ze standardem OAuth 2.0 z tokenami o czasie życia nieprzekraczającym 3600 sekund
- REQ-002: System musi obsługiwać minimum 1000 jednoczesnych użytkowników z czasem odpowiedzi nieprzekraczającym 200ms dla 95% żądań
- REQ-003: Interfejs użytkownika musi być zgodny z WCAG 2.1 poziom AA dla zapewnienia dostępności
- REQ-004: System musi generować logi audytowe w formacie JSON zgodnie z wewnętrznym standardem bezpieczeństwa
- REQ-005: Hasła użytkowników muszą spełniać politykę: minimum 8 znaków, zawierać wielkie i małe litery, cyfry oraz znaki specjalne
To są specyfikacje techniczne, nie User Story. Taka forma Backlogu pojawia się najczęściej, kiedy analityk biznesowy zostaje Product Ownerem i stare nawyki pozostają. Może być też sytuacja, że Deweloperzy nie chcą wziąć odpowiedzialności za budowanie produktu albo po prostu nie mają kompetencji. Wówczas poszczególne elementy będą tak bardzo opisane, że właściwie można je wkleić do narzędzia AI do generowania kodu.
Product Backlog jest żywy i ewoluuje. Nie dokumentuje wymagań – ułatwia rozmowy o wartości. Lepiej zacząć od: “Jako użytkownik chcę mieć pewność, że moje konto jest bezpieczne, żeby nie martwić się o kradzież danych osobowych”. Część wymagań trafi do Kryteriów Akceptacji poszczególnych User Story, ale może w trakcie refinementu dojdą nowe pomysły, jak lepiej zabezpieczyć dostęp do konta. Deweloperzy powinni wymyśleć, jak zaimplementować daną User Story, rozumiejąc jej kontekst.
Skąd się biorą takie błędy w budowaniu Backlogu Produktu?
Dlaczego ciągle wracamy do myślenia zadaniowego? Szczerze mówiąc, łatwiej jest myśleć zadaniami. To daje poczucie kontroli i przewidywalności. Wiemy, jak zrobić formularz logowania, ale czy wiemy, jak sprawić, żeby użytkownicy chcieli z niego korzystać
Zadania pozwalają utrzymać developerów zajętych. Outcome zmusza do myślenia o wyniku. Na szkoleniu w Gdańsku jeden z uczestników powiedział mi wprost: “Ale jak nie dam zespołowi listy zadań, to będą siedzieć bezczynnie”. Nie. Będą musieć myśleć. A to znacznie cenniejsze niż bycie zajętym.
Product Backlog to uporządkowana lista hipotez
Ostatecznie każdy element Product Backlogu to hipoteza: “Wierzymy, że dostarczenie tej funkcjonalności tej grupie użytkowników przyniesie taki efekt biznesowy”. User Story to nie wymaganie – to zaproszenie do rozmowy o wartości. “Jako… chcę… żeby…” to format, który pomaga zachować skupienie na efektach.
Product Backlog nie planuje pracy – priorytetyzuje eksperymenty. Nie mówi, jak coś zbudować – mówi, co warto zbadać jako pierwsze. To fundamentalna różnica między myśleniem projektowym a produktowym. Projekt wykonujemy zgodnie z planem. Produkt budujemy, ucząc się o potrzebach użytkowników. Dlatego na początku Product Backlog może być chaotyczny i niepełny. I to jest w porządku. Ważne, żeby każdy element odpowiadał na pytanie: “Jaką wartość to dostarcza i komu?”, “Od czego powinniśmy zacząć?”, a nie “Jakie zadania trzeba wykonać?”.
Jak lepiej tworzyć Product Backlog?
Można wykorzystać model INVEST, żeby sprawdzić czy to, co trafiło do Product Backlogu jest prawidłowym elementem backlogu, zwłaszcza w przypadku User Story. Ale jest też prostszy sposób.
Następnym razem, gdy będziesz tworzyć Backlog, zadaj sobie te pytania:
- Czy myślę o zadaniach do wykonania, czy o wartości do dostarczenia? Ten element brzmi jak zadanie czy opisuje zmianę w produkcie?
- Jeśli to wdrożę na produkcję, co zauważy użytkownik, jaką korzyść przyniesie mu korzystanie z tego?
- Co pokażę interesariuszom na Sprint Review? Czy będą rozumieli, co się zmieniło w produkcie i jak to na nich wpływa?
Podsumowanie
Product Backlog to jedyne miejsce, z którego Zespoły Scrum pobierają pracę, więc ma bezpośredni wpływ na planowanie Sprintów i na to, co finalnie zostanie dostarczone jako ukończony Przyrost Produktu. Dlatego też warto zadbać o to, żeby dostarczał właściwych informacji. Product Backlog to nie harmonogram projektu czy WBS, lecz narzędzie do odkrywania wartości. Nie ma być od początku kompletny ani technicznie szczegółowy – powinien za to prowokować do rozmów, testować hipotezy i skupiać uwagę zespołu na tym, co naprawdę istotne dla użytkownika.Zamiast pytać o zadania do wykonania, zacznij pytać: “Jaki efekt chcemy osiągnąć?”, “Co warto sprawdzić najpierw?”, “Co możemy pokazać interesariuszom?”, “Jakie korzyści dostarczamy użytkownikom?”. Taka zmiana myślenia to pierwszy krok w stronę prawdziwego podejścia produktowego.
