TWÓJ BACKLOG WYGLĄDA JAK PLAN. NIE JEST NIM.
Backlog produktowy w dużej organizacji wygląda jak wymagania zebrane w jeden przejrzysty plan. Ma strukturę, priorytety, opisy.
Niestety, większość itemów to założenia, których nikt nie sprawdził lecz przyjął jako pewnik.
TL;DR
Backlog produktowy nie jest listą wymagań. Jest listą założeń na temat tego czego chce klient. I dopóki tego nie weryfikujesz, zarządzasz zakładami, nie planem (Chyba, że pracujesz przy bukmacherce, to wtedy ok;) )
REFINEMENT. TRZY GODZINY. PIĘTNAŚCIE STORY.
Story przyszły z ekranami od UX. Rozpisane tak dokładnie, że wyglądają jak gotowa spec do implementacji. Każdy flow. Każdy stan. Kryteria akceptacji na trzy ekrany.
I tu pojawia się problem. Taki poziom szczegółowości przesuwa rozmowę na brzegi.
Macie co omawiać. Edge case’y, puste pola, obsługa błędów, mobile.
Mija czas. Doprecyzowujecie szczegóły. Ktoś pyta o kolejny edge case.
Zapisujecie komentarze.
Po trzech godzinach. Piętnaście story gotowych do sprintu.
Z jednej strony – super! Kawał zrobionej roboty.
Z drugiej – nikt nie zadał pytania: skąd mamy przekonanie, że to rozwiązuje realny problem klienta?
Bo ktoś powiedział, że ważne i tego potrzebuje?
JEDNO ROZRÓŻNIENIE
Backlog produktowy nie jest listą wymagań. Jest listą założeń o tym czego chce klient. Nikt ich nie zweryfikował.
Wymaganie mówi: „klient tego potrzebuje.” Założenie mówi: „myślimy że klient tego potrzebuje.”
To nie jest subtelna różnica. Wymaganie daje podstawę do decyzji. Założenie daje podstawę do zakładu. Każdy item w backlogu to zakład. Pytanie brzmi nie „czy to zrobimy”, ale „skąd wiemy, że warto”.
Kiedy pytam PO z dużych organizacji ile itemów w ich backlogu ma potwierdzenie że rozwiązują realny problem klienta, odpowiedź jest zwykle ta sama. Nie wiem. Nie mierzyliśmy tego.
Jest jeden wyjątek. Jeśli masz produkt gdzie wiesz dokładnie czego chce klient, znasz każde wymaganie z góry i masz 100% pewności że to co budujesz rozwiązuje jego problem, backlog jako plan ma sens.
Czy taki jest Twój produkt?
Spotkałem wielu PO, którzy byli przekonani że tak. Większość myliła się – nie dlatego, że byli niedbali, ale dlatego że organizacja przez lata nagradzała pewność siebie, a nie weryfikowanie założeń.
CO TO ZMIENIA W TWOJEJ ROLI
Jeśli backlog to lista założeń, refinement powinien zaczynać się od pytania: czy w ogóle warto to robić?
Przed każdym itemem rzadko pada jedno pytanie: skąd wiemy, że ten problem jest realny?
Brak weryfikacji wiąże się z podjęciem kosztownej decyzji: robimy. To drogi sposób sprawdzania potrzeb. Nawet w czasie AI.
Kiedy ostatnio rozmawiałeś z klientem – nie przez wymagania od interesariusza czy notatki z badań od UX. Tak samodzielnie?
Jeśli nie pamiętasz lub za zbieranie wymagań odpowiada ktoś inny w Twojej organizacji – to tam jest rozumienie klienta. A Ty przerabiasz te interpretacje na priorytety.
To niekomfortowe. Jesteś odpowiedzialny za decyzje produktowe bez dostępu do wiedzy, która je uzasadnia. Refinementy trwają, sprinty się kręcą, a poczucie, że coś nie gra zostaje.
To da się zmienić bez rewolucji procesowej. Zacznij od jednej rozmowy z klientem, który aktywnie używa Twojego produktu. Niech to nie będzie fancy warsztat czy ankieta. Na początek zwykła rozmowa. Zapytaj co próbuje zrobić, gdzie się zatrzymuje i co robi żeby sobie poradzić. Jedna taka rozmowa zmienia sposób w jaki patrzysz na backlog bardziej niż trzy miesiące refinementów.
PYTANIE, KTÓRE WARTO ZABRAĆ ZE SOBĄ
Oceń swój backlog. Jaki procent itemów w Twoim backlogu ma pokrycie, że rozwiązują realny problem klienta? A nie założenia od kogoś ze spotkania.
Jeśli ta liczba jest mała, warto zastanowić się jak to jest, że tak często dostarczony feature był uznawany za sukces.
I co sprawia że te założenia rosną szybciej niż wiedza o kliencie.
Jeśli chcesz skrócić backlog i zacząć pracować na tym co naprawdę warto zrobić, porozmawiajmy.
FAQ
Wymaganie zakłada że wiemy czego klient potrzebuje. Hipoteza przyznaje że to założenie do sprawdzenia. Różnica jest prosta. W praktyce backlog pełen jest hipotez zapisanych językiem pewności, bo „nie jesteśmy pewni” brzmi słabiej na spotkaniu z dyrektorem.
Nie każdy i nie zawsze. Ale powinieneś wiedzieć, które są założeniami i co ryzykujesz realizując je bez weryfikacji. Jeśli nie wiesz, działasz na ślepo.
Bo usunięcie itemu to polityczna decyzja. Ktoś go przecież zgłosił, potem poświęcono czas na opis i estymację i wyznaczenie priorytetu. Żeby wyrzucić, musisz komuś powiedzieć „twój pomysł nie jest wart realizacji.” Łatwiej przesunąć na dół i udawać że wrócimy do tego „później.” Product Backlog rośnie. Nikt nie płaci za jego sprzątanie.
Z mylenia aktywności z wartością. Product Backlog z 300 itemami wygląda jak dowód, że zespół ma co robić i że „rozumiemy potrzeby.” W rzeczywistości to 300 niezweryfikowanych zakładów. Im więcej ich masz, tym mniej wiesz co naprawdę robić. Ale optycznie wygląda produktywnie.
Przy każdym itecie zadaj jedno pytanie: skąd wiemy że ten problem jest realny? Tam gdzie nie ma odpowiedzi, masz zakład, nie wymaganie. Jeśli nie chcesz zadawać tego pytania głośno na refinemencie, to już masz odpowiedź dlaczego backlog wygląda tak jak wygląda.
Nie. Refinement porządkuje to co już jest w Product Backlogu. Discovery sprawdza czy to w ogóle warto tam wkładać. Większość zespołów robi refinement bez discovery, bo discovery wymaga rozmów z klientem, a refinement można zrobić wewnętrznie. Jest szybciej, wygodniej i nie wymaga wychodzenia ze swoich założeń.
WIĘCEJ Z TEJ SERII
- Roadmapa nie jest strategią. Jest kompromisem – LINK
- Feature thinking jako cichy zabójca strategii – [LINK]
- Discovery w dużej organizacji jest rytuałem, nie systemem – [LINK]