BACKLOG JAKO PLAN DZIAŁA. ALE TYLKO WTEDY GDY WIESZ NA 100% CO CHCE KLIENT.
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 to lista założeń o tym, czego chce klient, a nie lista wymagań. Dopóki ich 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.
Tu pojawia się problem. Taki poziom szczegółowości przesuwa rozmowę na brzegi. Macie co omawiać: edge case'y, puste pola, obsługę błędów, mobile. Mija czas. Doprecyzowujecie szczegóły. Ktoś pyta o kolejny edge case. Zapisujecie komentarze.
Po trzech godzinach piętnaście elementów backlogu jest gotowych do realizacji w kolejnym cyklu.
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 to lista założeń o tym, czego chce klient, a nie lista wymagań. Nikt ich nie zweryfikował.
Wymaganie mówi: „klient tego potrzebuje.” Założenie mówi: „myślimy, że klient tego potrzebuje.”
Różnica jest duża. 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”, tylko „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, w którym 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, lecz 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 oznacza kosztowną decyzję: robimy. To drogi sposób sprawdzania potrzeb. Nawet w czasie AI.
Kiedy ostatnio rozmawiałeś z klientem samodzielnie, nie przez wymagania od interesariusza ani notatki z badań od UX?
Jeśli nie pamiętasz albo za zbieranie wymagań odpowiada ktoś inny w Twojej organizacji, to tam siedzi rozumienie klienta. Ty przerabiasz te interpretacje na priorytety.
To niekomfortowe. Jesteś odpowiedzialny za decyzje produktowe bez dostępu do wiedzy, która je uzasadnia. Refinementy trwają, cykle delivery się kręcą, a poczucie, że coś nie gra, zostaje.
Da się to zmienić bez rewolucji procesowej. Zacznij od jednej rozmowy z klientem, który aktywnie używa Twojego produktu. Bez fancy warsztatu i ankiety. 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 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 możliwe, że tak często dostarczony feature uznawano 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
Czym różni się wymaganie od hipotezy w backlogu?
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.
Czy każdy item w backlogu musi być zweryfikowany?
Nie każdy i nie zawsze. Powinieneś jednak wiedzieć, które są założeniami i co ryzykujesz, realizując je bez weryfikacji. Jeśli nie wiesz, działasz na ślepo.
Dlaczego backlogi w dużych organizacjach są tak duże?
Bo usunięcie itemu to polityczna decyzja. Ktoś go przecież zgłosił, potem poświęcono czas na opis, 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.
Skąd bierze się przekonanie, że duży backlog to dobra rzecz?
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ć. Optycznie wygląda jednak produktywnie.
Jak zacząć traktować backlog jako listę hipotez?
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.
Czy refinement może zastąpić discovery?
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 da się zrobić wewnętrznie. Jest szybciej, wygodniej i nie wymaga wychodzenia ze swoich założeń.