Określenie “płacz i zgrzytanie zębów” to zgodnie z Wikisłownikiem fraza rzeczownikowa, rodzaj męskorzeczowy, a znaczenie jej jest następujące:

(1.1) bardzo trudna sytuacja, kłopot, zmartwienie

(1.2) ewangeliczne określenie mąk piekielnych[1] (etymologia: z Biblii: Ewangelia wg św. Mateusza 13, 41-50 i Mt 22, 13)

Chętnie dodałbym jeszcze jedno znaczenie “skutek słabego Refinementu” 🙂

Kilkukrotnie dołączałem do zespołów, które Refinement robiły bardzo słabo albo wręcz nie robiły go wcale. Przykładowe skutki:

• programowanie aplikacji niezgodnie z oczekiwaniem klienta,
• zapominanie o istotnych szczegółach rozwijanej funkcji,
• sporo czasu poświęcone na doprecyzowania w trakcie dewelopmentu,
• opóźnienia, wynikające z powyższego,
• zakurzony Backlog, a co za tym idzie coraz mniejszy sens jego utrzymywania.

Jest kilka patentów, które warto wypróbować, aby odpowiedzieć na takie problemy 😊

Regularność to podstawa

Regularność? Nudy, co? A jednak… jeśli raz w tygodniu przez 45-90 minut będziecie spotykali się, aby omawiać pomysły, to po miesiącu takich rozmów Wasz Backlog będzie w dużo lepszej kondycji. Zaufaj mi. Regularność to podstawa.

Z czasem może okazać się, że sesje mogą być krótsze, bo omawiacie tylko najświeższe pomysły. Po kilku miesiącach możesz mieć wręcz wrażenie, że w zasadzie mało jest do omówienia, nic nowego nie wpada. Taka sytuacja może kusić, aby odwołać jedną lub dwie sesje. Nie rób tego. Lepiej spotkać się i przez 10 minut pooglądać backlog, stwierdzić, że jest czysto. Jeśli porzucisz rutynę to potem trudno jest wrócić do niej ponownie. No i w 99% przypadków i tak okazuje się, że jednak ktoś coś ma do omówienia – a to jakiś bug nas zaskoczył, a to jakiś pomysł na refactoring kodu.

Jeśli nadal Cię będzie kusiło, to proponuję małą zabawę: nie odwołuj i zobacz co się stanie. Jeśli zmarnujecie czas to sygnał, że rzeczywiście warto robić refinement rzadziej.

Backlog jest trochę jak nasze domy – sprzątane rzadko wymagają dużego wysiłku, aby doprowadzić je do ładu. Sprzątane regularnie… no właśnie.

“Dlaczego”, rozmowy o problemie biznesowym

Prosty “trik” na pobudzenie kreatywności i zaangażowanie zespołu. Pokazywać “dlaczego?”, mówić o problemach biznesowych, use caseach zamiast od razu o rozwiązaniach.

Fajnie jak produktowiec przychodzi z pomysłem, ale im bardziej ten pomysł doprecyzowany na starcie, im sztywniejszy, tym trudniej włączyć się zespołowi i dyskutować. Dlatego polecam, gdy tylko to możliwe przynosić problemy biznesowe zamiast gotowych pomysłów.

Pisałem o tym już kilkukrotnie, np. w poście o Job Stories i Problem Stories, a także mówiłem o tym w podcaście Hansei Talks o angażowaniu deweloperów – sprawdź te linki 😎

Można zapytać zespół: “w ankiecie nasi klienci ocenili kreator dokumentów nisko, uważają że jest zbyt skomplikowany – od czego możemy zacząć jego upraszczanie?” Taka sytuacja bardziej otwiera dyskusje niż “musimy zaimplementować nowy kreator, który wygląda tak-a-tak”. Nie znaczy to, że nie możemy mieć sami zdania na dany temat, ale nie zaczynajmy od sztywnego, z góry narzuconego pomysłu.

Wizualizacja

Taka historia z życia, prawdziwa. Spotkanie online. Zespół rozmawiał o tym jak wykonać pewną historyjkę. Długo nie mogli się dogadać, a co jakiś czas okazywało się, że nie mówią wcale o tym samym i musieli sobie to wyjaśniać. Używali tylko słów. Odblokowali się, gdy tylko zaczęli rysować.

Jak tylko mogę to stosuję różne narzędzia wizualizacyjne:

• proste prototypy, nawet nabazgrane w Paincie,
• designy,
• pokazuję na ekranie, o które elemety mi chodzi,
• nagrania wideo, które pokazują interakcję z aplikacją,
• różne diagramy i schematy w Miro.

Chodzi o to, aby rozmów o zadaniu czy historyjce nie opierać jedynie o tytuł czy opis, a także o wizualizacje. Nie polegajmy tylko na naszych umiejętnościach komunikacyjnych, werbalnych, ale pomóżmy sobie ilustracjami.

Nie rozmawiajcie o elementach, których i tak nie zrobicie

Czasem dodajemy do Backlogu elementy “na kiedyś”. Wiemy już na starcie, że są bardziej z kategorii “miło byłoby mieć” niż “jeśli tego nie zrobimy to… “ 🙂 Zostaw dyskusje o nich na potem, a rozmawiajcie o tym co rzeczywiście ważne.

Może wydawać się rozsądne, że świeże pomysły warto od razu omówić, zrobić notatki i potem umieścić taki element gdzieś w środku Backlogu. Co do zasady, fajnie. Szkopuł w tym, że takie 15 minut poświęcone na średnioważny element, to 15 minut niepoświęcone na element ważny. Czy możesz sobie pozwolić na taki luksus?

Co więcej, za 3 miesiące, ten element może mieć jeszcze niższy priorytet. Z każdym dniem rośnie ryzyko, że spędzi jesień swojego życia w zapomnianych czeluściach Backlogu.

Zapraszaj ekspertów

Czy Biuro Obsługi Klienta wie o co chodzi narzekającym klientom i może pokazać przykłady maili lub reklamacji? A może handlowcy mają problem ze sprzedażą, bo jakaś funkcja jest niezrozumiała i mogą powiedzieć o swoich spostrzeżeniach? Kiedy indziej przyda się architekt, który wyjaśni jak podejść do zagadnienia technicznie, aby było spójne z resztą systemu.

Dla odświeżenia formuły albo by pozyskać dodatkową wiedzę, można zaprosić gości na spotkanie. Można tę wiedzę pozyskiwać inaczej, często zbiera ją Product Manager poza refinementem, ale nierzadko będzie ciekawiej, gdy cały zespół będzie mógł posłuchać o problemie i zadać własne pytania. Taka praktyka dodatkowo buduje mosty między działami, zespołami.

Przygotujcie się

Przed spotkaniem fajnie jest mieć na nie pomysł, listę tematów do omówienia.

Może korzystasz z JIRY? Fajnym patentem jest stworzenie oddzielnej sekcji (technicznie jest to pole “Sprint”), do której będziecie wrzucali wszystko co chcecie omówić na najbliższym spotkaniu. Albo jakiś label czy odpowiedni status, po którym będziecie filtrowali.

Można też zwyczajnie dorzucić do zaproszenia “oto lista rzeczy do omówienia”. Istotne, aby np. dzień wcześniej tematyka była znana. Pozwoli to innym się przygotować, przeczytać materiał.

Niby banalne, ale wiele razy widziałem jak pierwsze minuty spotkania tracone są na to, aby w ogóle znaleźć elementy, o których chcemy dyskutować.

Techniczny refinement? Czemu nie!

Pewne pomysły wymagają rozmów ściśle technicznych. Od strony biznesowej wiadomo co jest do zrobienia, ale technicznie jeszcze mamy wątpliwości. Nie powinniśmy zatem obawiać się robić refinementów technicznych, w których produktowcy nie biorą udziału.

Niektóre zespoły mają zwyczaj robić to na Planowaniu, po ustaleniu co chcą zrealizować w Sprincie, ale wówczas sesja Planowania jest dłuższa. Jeśli zatem chcecie mieć Sprint przygotowany także od strony technicznej, róbcie też refinement o takim charakterze 🙂

Dobry refinement to podstawa

Dobry refinement buduje solidną bazę. Łatwiej pisać aplikacje, które są właściwie przegadane. Wówczas też Sprinty są mniej stresujące. No i w ogóle życie jest lepsze 😉 Zachęcam Cię do samodzielnego przekonania się o tym. Powyżej znajdziesz kilka łatwych praktyk, z których zawsze można się wycofać, ale… sądzę, że nie będziecie chcieli tego zrobić ^_^ A jeśli coś tutaj pominąłem, to nie krępuj się, zjedź w dół strony i ciapnij nam swoje myśli w komentarzach.

P.S. Refinement nie musi przyjmować formy spotkania, ale w tym tekście tak o nim pisałem, bo w formie spotkania najczęściej bywa wykonywany. Pamiętaj jednak, że refinement to aktywność, w zasadzie stały proces i nie musisz ograniczać się tylko do spotkań.

---