Product Backlog łatwo zamienić w listę kilkuset ticketów zbieranych przez kilka lat. Są tam pomysły klientów, błędy, zadania techniczne, oczekiwania sprzedaży, inicjatywy managementu i funkcje, których nikt już nie pamięta. Teoretycznie wszystko jest zapisane. W praktyce coraz trudniej odpowiedzieć, nad czym zespół powinien pracować jako następnym.
Product Backlog nie jest magazynem wszystkich pomysłów dotyczących produktu. Jest uporządkowaną i stale rozwijającą się listą pracy potrzebnej do jego poprawy. W Scrumie jego punktem odniesienia jest Product Goal, czyli długoterminowy cel produktu, do którego Scrum Team zmierza poprzez kolejne Sprinty.
Scrum Guide określa Product Backlog jako wyłaniającą się, uporządkowaną listę tego, co jest potrzebne do ulepszania produktu, oraz jako jedyne źródło pracy podejmowanej przez Scrum Team.
Dobre zarządzanie backlogiem polega więc przede wszystkim na podejmowaniu decyzji o tym, co warto robić teraz, co później, a czego nie robić wcale.
Czym jest Product Backlog?
Product Backlog jest jednym z trzech artefaktów Scrum, obok Sprint Backlogu i Incrementu.
Składa się z:
- Product Goal, który wyznacza długoterminowy kierunek,
- Product Backlog Items, czyli elementów opisujących pracę potrzebną do rozwoju produktu.
Scrum.org podkreśla kilka ważnych właściwości Product Backlogu. Powinien być:
- jeden dla produktu,
- transparentny,
- aktualny,
- uporządkowany,
- rozwijany wraz ze zdobywaniem nowej wiedzy.
Ostatni punkt ma szczególne znaczenie.
Backlog nie jest specyfikacją projektu przygotowaną na początku i realizowaną punkt po punkcie.
Zmienia się, ponieważ zmieniają się:
- potrzeby użytkowników,
- wiedza zespołu,
- dane produktowe,
- rynek,
- technologia,
- ryzyka,
- priorytety biznesowe.
Element, który pół roku temu wydawał się ważny, dzisiaj może nie mieć żadnego uzasadnienia.
Product Goal – brakujący kontekst wielu backlogów
Największy chaos pojawia się wtedy, gdy każdy element backlogu wygląda na równie uzasadniony.
Sprzedaż potrzebuje funkcji A.
Klient enterprise prosi o funkcję B.
Development chce przebudować komponent C.
Management oczekuje inicjatywy D.
Support zgłasza dziesięć problemów.
Bez wspólnego kierunku Product Backlog szybko zmienia się w kolejkę oczekiwań różnych interesariuszy.
W Scrumie takim kierunkiem jest Product Goal.
Scrum Guide określa Product Goal jako przyszły stan produktu, który może służyć Scrum Teamowi jako cel planowania. Jest on zobowiązaniem przypisanym do Product Backlogu, a pozostała część backlogu rozwija się, aby określić, co pomoże ten cel osiągnąć.
Scrum.org opisuje go dodatkowo jako pomost między szerszą wizją produktu a celami kolejnych Sprintów. W danym momencie Scrum Team pracuje względem jednego Product Goal, przed przyjęciem kolejnego, obecny powinien zostać osiągnięty albo świadomie porzucony.
Przykład:
Zamiast ogólnego:
rozwijać platformę samoobsługową
cel może wskazywać konkretny przyszły stan:
umożliwić nowym klientom uruchomienie podstawowej usługi bez kontaktu z supportem.
Taki Product Goal daje filtr dla backlogu.
Element dotyczący automatycznej konfiguracji konta może bezpośrednio wspierać cel.
Zmiana wyglądu strony raportów może być wartościowa, ale niekoniecznie musi znaleźć się wysoko właśnie teraz.
Product Backlog nie powinien być listą wszystkich pomysłów
Jednym z częstych antywzorców jest używanie backlogu jako przechowalni.
Pomysł pojawia się podczas spotkania:
dodajmy do backlogu.
Klient wspomniał o funkcji:
dodajmy do backlogu.
Ktoś zauważył możliwość usprawnienia:
dodajmy do backlogu, żeby nie zapomnieć.
Po kilku latach powstają setki elementów, z których ogromna część nigdy nie zostanie zrealizowana.
Scrum.org wskazuje używanie Product Backlogu jako magazynu pomysłów jako jeden z typowych antywzorców. Zbyt duży backlog zwiększa szum, utrudnia dostrzeżenie wartościowych elementów i może pogarszać komunikację z interesariuszami.
Nie każdy pomysł musi więc trafiać do Product Backlogu.
Można posiadać osobny obszar discovery, repozytorium pomysłów czy bazę feedbacku klientów.
Do właściwego Product Backlogu powinny trafiać przede wszystkim te elementy, które mają realne znaczenie dla bieżącego lub przewidywalnego rozwoju produktu.
Jeden produkt – jeden Product Backlog
Kolejnym źródłem chaosu jest tworzenie osobnych backlogów:
- dla developmentu,
- dla bugów,
- dla UX,
- dla długu technicznego,
- dla security,
- dla konkretnych zespołów.
W efekcie nie istnieje już jedno miejsce, w którym można ocenić wszystkie konkurujące ze sobą potrzeby.
Scrum.org wskazuje, że dla jednego produktu powinien istnieć jeden Product Backlog. Dotyczy to również sytuacji, gdy nad tym samym produktem pracuje kilka Scrum Teams. Nie tworzy się osobnego Product Backlogu tylko dlatego, że jeden element jest błędem, a drugi pracą UX czy techniczną.
Ma to praktyczne znaczenie.
Jeżeli zespół ma:
Backlog funkcji
oraz osobny:
Backlog długu technicznego
to Product Owner nigdy nie musi bezpośrednio zestawić ze sobą:
nowej funkcji wartej określony rezultat
oraz:
przebudowy obszaru, którego obecny stan zwiększa ryzyko awarii.
Jeden backlog wymusza widoczność trade-offów.
Co może być Product Backlog Item?
Scrum nie narzuca jednego formatu Product Backlog Item.
Nie każdy element musi być User Story zaczynającą się od:
Jako użytkownik chcę…
PBI może reprezentować między innymi:
- nową funkcjonalność,
- usprawnienie,
- błąd,
- eksperyment,
- zmianę techniczną,
- pracę bezpieczeństwa,
- potrzebę związaną z wydajnością,
- element discovery.
Scrum Guide celowo nie określa sztywnego zestawu atrybutów. Podczas refinementu elementy mogą zyskiwać szczegóły takie jak opis, kolejność i rozmiar, ale konkretna forma zależy od rodzaju pracy.
Najważniejsze nie jest więc zastosowanie właściwego szablonu.
Dobry Product Backlog Item powinien pozwalać zespołowi zrozumieć:
- po co praca jest potrzebna,
- jaki problem rozwiązuje,
- jakiego rezultatu oczekujemy,
- wystarczająco dużo szczegółów, aby w odpowiednim momencie podjąć decyzję o realizacji.
Product Backlog jest uporządkowany, nie tylko priorytetyzowany
Scrum Guide używa określenia ordered, czyli uporządkowany.
To szersze pojęcie niż proste przypisywanie priorytetu:
- High,
- Medium,
- Low.
Product Owner może uwzględniać podczas ustalania kolejności między innymi:
- wartość dla użytkownika,
- znaczenie biznesowe,
- ryzyko,
- potrzebę zdobycia wiedzy,
- zależności,
- koszt,
- ROI,
- pilność,
- wpływ na Product Goal.
Scrum.org właśnie wartość, ryzyko, ROI, zależności i wpływ wymienia jako przykładowe czynniki wpływające na kolejność backlogu.
Dzięki temu dwa elementy oznaczone jako wysoki priorytet nadal mogą mieć jednoznaczną kolejność.
Przykład:
| PBI | Wartość | Ryzyko / wiedza | Zależności | Decyzja |
|---|---|---|---|---|
| Automatyczne utworzenie konta | Wysoka | Średnie | Niskie | Wysoko |
| Integracja z dostawcą KYC | Wysoka | Bardzo wysokie | Blokuje kolejne funkcje | Jeszcze wyżej |
| Nowy wygląd dashboardu | Średnia | Niskie | Brak | Później |
Integracja KYC może zostać wykonana wcześniej nie dlatego, że daje natychmiast większą wartość użytkownikowi, ale ponieważ wcześniej ogranicza ryzyko całego kierunku produktu.
Nie każda najważniejsza praca jest funkcją dla użytkownika
Zespół może mieć pokusę, żeby backlog wyglądał atrakcyjnie dla biznesu:
- nowe dashboardy,
- nowe raporty,
- nowe integracje,
- nowe funkcje.
Tymczasem produkt wymaga również pracy, której użytkownik bezpośrednio nie zobaczy.
Przykłady:
- aktualizacja zależności,
- usunięcie ryzyka bezpieczeństwa,
- automatyzacja deploymentu,
- poprawa obserwowalności,
- zmniejszenie czasu odpowiedzi API,
- przebudowa komponentu utrudniającego dalszy rozwój.
Jeżeli taka praca konkuruje o czas Scrum Teamu, również powinna być transparentna.
Atlassian zwraca uwagę, że dobry backlog obejmuje zarówno pracę widoczną dla klienta, jak i wewnętrzne zadania techniczne, dzięki czemu interesariusze mogą świadomie rozmawiać o trade-offach.
Ukrywanie długu technicznego poza backlogiem prowadzi natomiast do sytuacji, w której wygląda on na bezkosztowy.
Jak uporządkować chaotyczny Product Backlog?
Jeżeli backlog ma kilkaset elementów, nie zaczynałbym od estymowania wszystkiego.
Najpierw trzeba odzyskać fokus.
Zacznij od Product Goal
Sprawdź, czy Scrum Team posiada jeden zrozumiały cel produktu.
Jeżeli nie można określić, do jakiego przyszłego stanu produktu zespół zmierza, uporządkowanie ticketów będzie głównie administracją.
Product Goal powinien dać odpowiedź na to, jakiego istotnego efektu oczekujemy, a nie być listą Features do wykonania.
Usuń elementy, które utraciły znaczenie
Przyjrzyj się starszej części backlogu.
Jeżeli dany element:
- od dawna nie był poruszany,
- nie wspiera aktualnego kierunku,
- nikt nie potrafi uzasadnić jego wartości,
- opiera się na nieaktualnym założeniu,
warto rozważyć jego usunięcie.
Usunięcie PBI nie oznacza, że pomysł był zły.
Oznacza tylko, że nie ma obecnie wystarczającego uzasadnienia, aby konkurował o uwagę zespołu.
Scrum.org zaleca utrzymywanie backlogu w rozsądnym rozmiarze, ponieważ jego nadmierny wzrost zmniejsza przejrzystość i powoduje marnowanie czasu na utrzymywanie mało istotnych elementów.
Grupuj pracę wokół rezultatów, nie działów
Jeżeli backlog wygląda tak:
Backend
- API A
- API B
Frontend
- ekran A
- ekran B
UX
- projekt ekranu A
łatwo stracić z oczu wartość końcową.
Lepszym kontekstem może być rezultat:
Klient samodzielnie aktywuje konto
pod którym pojawiają się potrzebne elementy backendu, UI czy integracji.
To ułatwia rozmowę o tym, po co powstaje praca, zamiast skupiać się wyłącznie na komponentach technicznych.
Product Backlog refinement – co naprawdę oznacza?
Refinement nie jest spotkaniem, które Scrum Guide wymaga organizować w każdą środę o 14:00.
Jest ciągłą aktywnością polegającą na rozbijaniu i doprecyzowywaniu elementów Product Backlogu, aż będą wystarczająco zrozumiałe do dalszej pracy.
Scrum Guide mówi o dodawaniu podczas refinementu takich informacji jak opis, kolejność i rozmiar. Elementy, które Scrum Team może ukończyć w jednym Sprincie, są uznawane za gotowe do rozważenia podczas Sprint Planningu.
Scrum.org dodatkowo podkreśla, że refinement:
- może odbywać się wiele razy w Sprincie,
- może mieć formę spotkania lub działań wykonywanych w razie potrzeby,
- nie jest formalnym wydarzeniem Scrum.
Nie chodzi więc o wykonanie ceremonii.
Celem jest wspólne zrozumienie najbliższej pracy.
Nie doprecyzowuj całego backlogu
Jeżeli backlog zawiera 300 elementów, szczegółowe opisanie i oszacowanie wszystkich może być ogromnym marnotrawstwem.
Produkt w międzyczasie się zmieni.
Część pomysłów straci znaczenie.
Nowe dane zmienią priorytety.
Scrum.org wskazuje nadmierne dopracowywanie odległej części backlogu jako antywzorzec. Inwestowanie dużej ilości czasu w szczegóły pracy, która być może nigdy nie zostanie wykonana, zwiększa ryzyko waste.
Znacznie lepiej stosować różny poziom szczegółowości.
Góra backlogu:
- lepiej zrozumiana,
- mniejsze elementy,
- więcej danych,
- możliwa do omawiania podczas najbliższego Sprint Planningu.
Dalsza część:
- większe elementy,
- więcej hipotez,
- mniej szczegółów.
Jeszcze dalsza:
- kierunki,
- problemy,
- pomysły wymagające discovery.
Im bliżej realizacji, tym więcej inwestujesz w doprecyzowanie.
Refinement powinien zmniejszać niepewność, a nie produkować dokumentację
Dobry refinement może doprowadzić do różnych rezultatów.
PBI może zostać:
- lepiej opisany,
- rozbity,
- przesunięty wyżej,
- przesunięty niżej,
- połączony z innym,
- skierowany do eksperymentu,
- usunięty.
Usunięcie elementu po refinement może być równie dobrym rezultatem jak jego przygotowanie do developmentu.
Jeżeli rozmowa ujawnia, że problem użytkownika nie jest wystarczająco istotny, najbardziej wartościową decyzją może być właśnie nie budować rozwiązania.
Kto odpowiada za Product Backlog?
Product Owner jest odpowiedzialny za skuteczne zarządzanie Product Backlogiem.
Obejmuje to między innymi:
- tworzenie i komunikowanie Product Goal,
- tworzenie i jasne komunikowanie Product Backlog Items,
- ustalanie ich kolejności,
- zapewnianie transparentności i zrozumiałości backlogu.
Scrum Guide pozwala Product Ownerowi delegować część tej pracy, ale odpowiedzialność pozostaje po jego stronie.
Scrum.org ujmuje to bardzo praktycznie: Product Owner ostatecznie decyduje, nad czym warto pracować teraz, później albo wcale.
Nie oznacza to jednak, że Product Owner powinien samotnie pisać wszystkie tickety.
Efektywne zarządzanie backlogiem wymaga współpracy z:
- Developers,
- użytkownikami,
- interesariuszami,
- supportem,
- sprzedażą,
- specjalistami domenowymi.
Product Owner odpowiada za decyzję, ale dobra decyzja potrzebuje informacji.
Developers również mają ważną rolę
Jednym z błędów jest model:
Product Owner pisze wymagania → Developers dostają gotowe tickety do wykonania.
To wraca do modelu przekazywania specyfikacji.
Developers uczestniczą w refinement, ponieważ wnoszą wiedzę o:
- rozwiązaniu,
- ryzyku technicznym,
- zależnościach,
- możliwościach podziału pracy,
- koszcie,
- alternatywnych sposobach rozwiązania problemu.
Scrum Guide wskazuje również, że to Developers wykonujący pracę odpowiadają za sizing Product Backlog Items. Product Owner może pomagać w zrozumieniu trade-offów, ale nie powinien narzucać zespołowi estymat.
Refinement jest więc współpracą, nie przekazaniem ticketów.
Product Backlog a Sprint Backlog – nie mieszaj tych artefaktów
Product Backlog odpowiada przede wszystkim na pytanie:
co może być potrzebne do rozwoju produktu?
Sprint Backlog przedstawia plan Developers na konkretny Sprint.
Zawiera:
- Sprint Goal,
- Product Backlog Items wybrane do Sprintu,
- plan osiągnięcia celu.
Scrum.org podkreśla, że Sprint Backlog jest tworzony przez Developers podczas Sprint Planning i aktualizowany w trakcie Sprintu wraz ze zdobywaniem nowej wiedzy.
To oznacza, że Product Owner nie powinien podczas Sprintu po prostu przenosić kolejnych elementów Product Backlogu do Sprint Backlogu.
Product Backlog może zmieniać się cały czas.
Sprint natomiast posiada Sprint Goal, którego zespół chroni podczas realizacji.
Product Backlog a roadmap – to również nie jest to samo
Roadmap pokazuje szerszy kierunek produktu.
Może komunikować:
- problemy, które firma chce rozwiązać,
- oczekiwane rezultaty,
- większe obszary inwestycji,
- horyzont kolejnych decyzji.
Product Backlog jest bardziej operacyjny.
To uporządkowana reprezentacja pracy potrzebnej do poprawy konkretnego produktu.
Dlatego roadmap nie powinna być po prostu Product Backlogiem wyświetlonym w układzie kwartalnym.
Jeżeli roadmap zawiera 60 z góry określonych Features przypisanych do kolejnych sześciu miesięcy, łatwo zamienić ją w klasyczny plan projektu ubrany w terminologię Agile.
Product Goal pozwala zachować kierunek, pozostawiając przestrzeń do uczenia się, jak najlepiej ten cel osiągnąć.
Jak zarządzać pomysłami interesariuszy bez zaśmiecania backlogu?
Product Owner często znajduje się pod presją wielu źródeł.
Każda osoba chce mieć gwarancję, że jej pomysł nie zniknie.
Można oddzielić capture od commitment.
Przykładowy przepływ:
feedback / pomysł → analiza → decyzja → Product Backlog
Nie wszystko musi trafiać bezpośrednio do backlogu.
Pomysły można zbierać w:
- systemie feedbacku,
- CRM,
- narzędziu discovery,
- osobnej bazie insightów.
Dopiero po ocenie problemu część z nich staje się kandydatem do Product Backlogu.
To ogranicza sytuację, w której backlog staje się systemem CRM dla Product Ownera.
Automatyzacja może pomóc uporządkować napływ pracy
W większej organizacji Product Owner może otrzymywać informacje z wielu kanałów:
- supportu,
- sprzedaży,
- formularzy,
- CRM,
- analytics,
- badań użytkowników.
Część pracy administracyjnej można automatyzować.
Przykładowy workflow:
zgłoszenie klienta → zapis w centralnym repozytorium feedbacku → klasyfikacja → wykrycie potencjalnego duplikatu → przypisanie obszaru produktu → analiza przez Product Ownera
AI może pomagać między innymi:
- grupować podobny feedback,
- tworzyć streszczenia,
- wykrywać powtarzające się problemy,
- wyszukiwać podobne zgłoszenia,
- przygotowywać kontekst do refinementu.
Nie powinno to jednak prowadzić do automatycznego:
ticket zgłoszony przez dużego klienta → Priority: Highest → Product Backlog.
Priorytetyzacja produktu wymaga kontekstu strategicznego, kosztu alternatywnego i odpowiedzialności Product Ownera.
Automatyzuj zbieranie i porządkowanie informacji, nie odpowiedzialność za decyzję produktową.
Jak mierzyć zdrowie Product Backlogu?
Nie ma jednej oficjalnej metryki zdrowego backlogu.
Można jednak obserwować kilka praktycznych sygnałów.
Liczba bardzo starych elementów
Jeżeli duża część backlogu nie była analizowana od miesięcy, warto sprawdzić, czy nadal reprezentuje realne potrzeby.
Nie chodzi o osiągnięcie konkretnego limitu.
Chodzi o regularne usuwanie pracy, która przestała mieć znaczenie.
Gotowość góry backlogu
Najbliższa praca powinna być wystarczająco zrozumiała, żeby podczas Sprint Planning zespół nie rozpoczynał analizy problemu od zera.
Powiązanie z Product Goal
Sprawdź, czy elementy znajdujące się wysoko można logicznie powiązać z obecnym kierunkiem produktu.
Jeżeli większość najbliższej pracy nie ma związku z Product Goal, albo cel jest źle zdefiniowany, albo backlog stracił fokus.
Tempo pojawiania się i usuwania elementów
Zdrowy backlog nie tylko rośnie.
Powinny z niego również znikać:
- zrealizowane elementy,
- pomysły odrzucone,
- potrzeby nieaktualne,
- elementy zastąpione lepszym rozwiązaniem.
Backlog, który od dwóch lat wyłącznie rośnie, prawdopodobnie pełni funkcję archiwum.
Najczęstsze błędy w zarządzaniu Product Backlogiem
Wszystko ma wysoki priorytet
Jeżeli dwadzieścia elementów jest oznaczonych jako Highest, etykieta przestaje dostarczać informacji.
Potrzebna jest kolejność i trade-off.
Backlog ma osobny koszyk dla każdego interesariusza
Sprzedaż ma własne elementy, IT własne, management własne.
Brakuje jednej decyzji produktowej o tym, co daje największą wartość.
Każdy element jest szczegółowo opisany wiele miesięcy wcześniej
Zespół inwestuje czas w wiedzę, która może przestać być aktualna przed rozpoczęciem realizacji.
Product Owner jest administratorem Jira
Większość czasu zajmuje przepisywanie opisów, zmienianie statusów i organizowanie ticketów.
Tymczasem najważniejszą odpowiedzialnością jest maksymalizacja wartości produktu poprzez dobre decyzje o kierunku pracy.
Backlog jest aktualizowany tylko przed Sprint Planning
Scrum.org wskazuje brak regularnej pracy Product Ownera z backlogiem jako antywzorzec. Jeżeli aktualizacja odbywa się dopiero przed kolejnym Sprintem, trudniej utrzymać go jako aktualne źródło decyzji.
Refinement zamienia się w estymowanie
Zespół spędza godzinę, próbując zdecydować, czy element ma 5 czy 8 Story Points, ale nadal nie rozumie:
- jaki problem rozwiązuje,
- po czym pozna sukces,
- czy w ogóle warto go budować.
Estymata nie zastępuje zrozumienia wartości.
Nigdy nic nie jest usuwane
Argument brzmi:
może kiedyś do tego wrócimy.
Jeżeli kiedyś problem ponownie stanie się ważny, prawdopodobnie wróci również jego sygnał.
Nie trzeba utrzymywać każdej możliwości przez wiele lat.
Przykład: backlog funkcji kontra backlog skupiony na celu
Firma rozwija platformę B2B.
Product Backlog zawiera między innymi:
- nowy dashboard,
- eksport XLSX,
- integrację CRM,
- zmianę onboardingu,
- nowy raport,
- API do konfiguracji,
- redesign ustawień,
- automatyczne powiadomienia,
- obsługę kolejnego języka.
Każdy pomysł jest sensowny.
Problem polega na tym, że nie wiadomo, który jest najważniejszy teraz.
Zespół definiuje Product Goal:
nowy klient może samodzielnie skonfigurować konto i rozpocząć korzystanie z podstawowej usługi.
Backlog zaczyna wyglądać inaczej.
Wyżej trafiają:
- uproszczenie procesu onboardingu,
- API konfiguracji,
- automatyczna walidacja danych,
- komunikaty błędów,
- integracja potrzebna do uruchomienia usługi.
Nowy raport nadal może być dobrym pomysłem.
Nie pomaga jednak bezpośrednio osiągnąć aktualnego Product Goal, dlatego pozostaje niżej.
Po kilku Sprintach dane pokazują, że użytkownicy nadal zatrzymują się na etapie wprowadzania informacji z zewnętrznego systemu.
Zespół zmienia kolejność backlogu.
Integracja zyskuje większe znaczenie.
To nie oznacza, że wcześniejszy plan był błędny.
Product Backlog powinien właśnie adaptować się na podstawie nowej wiedzy.
Prosty sposób na odzyskanie kontroli nad Product Backlogiem
Jeżeli backlog jest już przeładowany, nie próbuj naprawiać wszystkich elementów jednocześnie.
Najpierw upewnij się, że istnieje jasny Product Goal.
Następnie skup się na górnej części Product Backlogu i sprawdź, czy naprawdę reprezentuje najważniejszą pracę potrzebną do osiągnięcia tego celu. Usuń lub odsuń elementy, których znaczenia nie da się już uzasadnić.
Dalszą część backlogu pozostaw mniej szczegółową. Nie inwestuj w refinement pracy tylko dlatego, że kiedyś może zostać wykonana.
Regularnie wracaj do kolejności wraz z:
- feedbackiem użytkowników,
- wynikami kolejnych Incrementów,
- informacjami ze Sprint Review,
- zmianą ryzyka,
- nowymi ograniczeniami technicznymi.
Scrum.org opisuje zarządzanie Product Backlogiem jako ciągłe tworzenie, refinement i ordering, których celem jest umożliwienie Scrum Teamowi dostarczania możliwie wartościowego produktu.
Dobrze zarządzany Product Backlog nie musi być bardzo rozbudowany.
Powinien przede wszystkim sprawiać, że zespół i interesariusze rozumieją dokąd zmierza produkt, jaka praca jest obecnie najważniejsza i dlaczego właśnie ona powinna zostać wykonana przed innymi możliwościami.
To jest znacznie ważniejsze niż idealnie opisane 500 ticketów.
