Backlog Refinement, do którego nie mogę się przyczepić.

book

Wiedza | PROCES

W poprzednim artykule pisałam o tym, czym jest Backlog Refinement zgodny ze sztuką scrumową. Dzisiaj spojrzymy na niego z praktycznego punktu widzenia. Na przykładzie. Przedstawiam Backlog Refinement, do którego jako konsultant naprawdę nie mogę się czepić.

 

Do przedstawienia typowego scenariuszu posłużę się przykładem z jednego z zespołów, z którym współpracowałam. Oczywiście zmieniam imiona, aby zespołu nie dało się go wyśledzić.

Nad Backlogiem Produktu pracują dwa Zespoły Deweloperskie oraz Właściciel Produktu, Kamil. Refinementy odbywają się raz na dwutygodniowy Sprint, zwykle trwają około półtorej godziny.

Dwa dni przed wydarzeniem Kamil wysyła zespołom listę elementów Backlogu Produktu, nad którymi chciałby popracować wraz z tym, co należy z nimi zrobić. Np.:

–           Wprowadzenie obsługi urządzenia X – podzielić na mniejsze i wyestymować.

–           Refactoring obsługi macierzy – podzielić na mniejsze i wyestymować.

–           Błąd kolorowania składni – wyestymować.

–           Dodanie obsługi typu A do funkcji B – dodać warunki akceptacji, reestymować.

–           Przedyskutować wyniki ankiety zadowolenia użytkowników.

Prosto z Daily cały zespół przenosi się do sali konferencyjnej, ktoś po drodze chwyta kartonik z kartami do estymacji, Kamil podłącza się do rzutnika i prezentuje agendę.

           – Zaczynamy? – Pyta.

           – Tak. – Dochodzą do niego nieco rozespane głosy.

Kamil wyświetla pierwszy element agendy.

Następnie wyciąga z torby sporą skrzynkę.

           – No to mamy X. Udało mi się załatwić dla was fizyczne urządzenie. – Cały zespół otwiera szeroko oczy i wyciąga ręce do urządzenia. – Dostajemy coraz więcej zapytań dotyczących obsługi X w naszej aplikacji, 5 w ostatnim tygodniu. Urządzenie zrobiło się ostatnio bardzo popularne. Dlatego przesunąłem je do góry Backlogu, w sumie najchętniej rozpocząłbym pracę nad tym w następnym Sprincie. Na razie mamy to wyestymowane na 30, więc koniecznie trzeba to podzielić, do zrobienia jest 6 metod. Może wyestymujemy, każdą po kolei i w ten sposób podzielimy to zadanie?

           – No możemy, ale – odezwał się Maciej – ponieważ nie mieliśmy jeszcze do czynienia z takim typem, to proponuje wziąć na tapetę najprostsze, wyestymujmy je dzisiaj. Zrobimy w przyszłym Sprincie i na następnym Refinemencie będziemy mieli przetarte szlaki i wyestymujemy resztę dokładniej.

– Brzmi rozsądnie – potakuje reszta zespołu

– To zróbmy samo połączenie.

– To mi się wydaje małe.

– W ten sposób niewiele się dowiemy.

– Zróbmy połączenie i sprawdzenie jednego z parametrów.

– Ma rację, zróbmy tak, co ty na to Kamil?

– Miałem nadzieje na w miarę pewną estymację już dziś, ale brzmi rozsądnie. Estymujcie.

Zespół bierze karty.

Kamil w tym czasie tworzy nowy element Backlogu Produktu. Nazywa go „Połączenie z X”. Wewnątrz wpisuje tytuł: „Warunki akceptacji”:

– Myślę, że obsługa samego połączenia będzie standardowa. Podyktujecie mi?

Zespół dyktuje 7 kolejnych elementów.

           – Estymujemy? – pyta Kamil?

Każdy kładzie przed sobą kartę z estymacją. Ktoś mówi:

           – Odwracamy.

Cały zespół odwraca, dwie osoby mają 5, trzy osoby 13.

           – Co wy chcecie tu robić na 13.

           – Wiesz to nowe urządzenie, różni się od tych do tej pory obsługiwanych.

 

Zaczyna się dyskusja.

Tak mniej więcej przebiega całe spotkanie. Może zauważyliście, że Scrum Master nie odezwał się ani razu. Jest to typowe w standardowym przebiegu. Jeżeli jednak okazałoby się, że:

– zespół nie jest tak dobrze nastawiony do przesunięcia tego elementu na górę Backlogu Produktu, bo przecież umówili się na refaktoring,

– estymacje powodują dużo emocji i dogadać się jest trudno,

– Właściciel Produktu przychodzi na spotkanie nieprzygotowany,

to pracy dla Scrum Mastera jest pod dostatkiem. A nie oszukujmy się, tworzenie oprogramowania jest trudne i rzadko wszystko przebiega gładko. Im więcej jednak sobie pomożemy tym będzie łatwiej. Jak sobie pomóc?

Dobre rady cioci Beaty: Backlog Refinement

Podam wam 3 absolutne podstawy i 3 hinty. Jeżeli coś jest nie tak z waszym procesem Refinementu, to tam należy szukać.

Absolutne podstawy:

  1. Jeden Właściciel Produktu

    . Nie widziałam dobrego Backlogu Produktu, którym opiekuje się wiele osób. Jeden Właściciel Produktu to jedna z najczęściej łamanych zasad Scruma i niestety jedna z najbardziej szkodliwych. Konsekwencje:

Na Refinemencie mamy reprezentanta osoby decyzyjnej, który nie do końca rozumie decyzje, które właśnie komunikuje.

Mamy komitet dwóch -trzech równoważnych osób, które zamiast prezentować co jest do zrobienia, ścierają się ze sobą.

Chcecie mieć dobry Produkt, postawcie na stanowisku Właściciela Produktu jedną decyzyjną osobę, która też tego chce i ma na to czas.

  1. Jeden Backlog Produktu.

    Podstawą dobrego planowania jest jeden spójny plan. Utrzymywanie porządku w jednym miejscu jest trudne, a utrzymywanie go w wielu, jeszcze trudniejsze. Najczęściej koncentrujemy się wtedy na porządku w jednym z backlogów a reszta zarasta chwastami. Jak Backlog Produktu najczęściej się mnoży:

osobna lista błędów,

oddzielna lista małych ulepszeń,

 różne listy na prac odłożonych na później,

 niezależny backlog dla tej jednej części systemu,

osobny backlog długu technicznego do którego nikt nie zagląda.

Wszystkie te listy powinny być osobnymi typami w tym samym Backlogu Produktu.

  1. Zapominanie o wartości biznesowej

    czyli ważnych powodach, dla których robimy właśnie to a nie co innego. Po pierwsze dają one zespołowi podstawy do podejmowania decyzji, inaczej robimy funkcjonalność dla trzylatka inaczej dla stutrzylatka. Dają motywację do angażowania się w tworzenie produktu. Rozmawianie o wartości jest warunkiem koniecznym dobrego Refinementu.

Teraz czas na hinty:

  1. Bez dobrego planu nie ma dobrego produktu,

    a więc sesje  Backlog Refinement należy traktować poważnie i przygotowywać się do nich. Jeden z najlepszych zespołów które znałam, wyznaczał osoby, które mają się przygotować z określonych elementów Backlogu Produktu do sesji Refinementu, tak aby tylko jedna osoba poświęcała na to czas. Kluczem do sukcesu jest balans między planowaniem a egzekwowaniem planu.

  2. Unikanie rozmów o technicznych aspektach omawianych elementów Backlogu Produktu.

    Jeżeli mamy tendencję do zagłębianie się w techniczne detale to najczęściej nie ma już czasu na zagłębienie się w to, po co to robimy i dla kogo. A nasze rozkminki techniczne i tak po zderzeniu z rzeczywistością często okazują się kompletnie nieprzydatne.

  3. Spojrzenie na całość.

    Od czasu do czasu przydaje się Refinement, na którym nie omawiamy konkretnych elementów Backlogu Produktu, ale patrzymy na cały plan. Sprawdzamy czy nasz jest spójny. Czy estymacje są nadal aktualne. Jak jest ze zrozumieniem Backlogu od początku do końca? Czy rozumiemy wizję Właściciela Produktu. Przydatne techniki to: story mapping, macierz Eisenhowera, value stream mapping, event storrming. Takie Refinementy sprawiają, że nie robimy zadań, tylko tworzymy produkt. Wyobraźmy sobie dwie osoby kopiące rów, zapytane, co robią, jedna może odpowiedzieć „kopie rów” a druga „buduje katedrę”. Nie stworzymy świetnego produktu zespołami, które realizują zadania, bo decyzje, które oni podejmują muszą być zgodne z misją i wizją produktu. Więc zespół musi ją znać i rozumieć, a najlepiej nią żyć, przynajmniej zawodowo.

 

Powodzenia, w prowadzeniu świetnych Backlog Refinement. Jeżeli macie jakieś pytania, uwagi, sugestie śmiało piszcie o tym w komentarzach.

 

Najlepsze artykuły:

Powiązane artykuły, mogą Cię też zainteresować!

Product Backlog Refinement - zgodny ze sztuką

Product Backlog Refinement to proces porządkowania i uaktualniania Backlogu Produktu.

Po co nam dobry Product Backlog?

W Scrumie za jakość odpowiada zespół deweloperski. Zespół. Nie manager. Nie Produkt Owner. Nie Scrum Master.Zespół dewel...

Dziel i zwyciężaj - jak dbać Product Backlog

Dlaczego dzielenie zadań jest tak ważne z technicznego punktu widzenia? Otóż dlatego, że  najwięcej niespodzianek jest n...

Czy warto suszyć i całować Product Backlog?

Każda osoba w zespole deweloperskim podejmuje codziennie dziesiątki decyzji. Mogę one wspierać wizję Product Ownera i je...

Najlepsze artykuły: