Co mierzy dobry Product Owner, odcinek #4/5 Jak zmierzyć ILOŚĆ?

Spis Treści

Co mierzy dobry Product Owner, odcinek #4/5 Jak zmierzyć ILOŚĆ?

Co mierzy dobry Product Owner?

Myślałem, że ten odcinek będzie najłatwiejszy. Tak bardzo się myliłem…

Według mojej pierwotnej wizji, treść miała być inna od tego co zaraz przeczytasz. Moje kłopoty zaczęły się, kiedy postanowiłem zapytać kilku znajomych Product Managerów i Product Ownerów z jakich narzędzi do mierzenia ilości korzystają w ich organizacjach. Okazało się, że nawet używając odpowiednich narzędzi i posiadając dane, nie w każdej organizacji wiedzą o czym te dane świadczą i jak z nich korzystać.

Najgorszą historię, którą usłyszałem podczas wywiadów, była historia znajomego Product Ownera z Warszawy, o tym jak w organizacji, dla której obecnie pracuje, zarząd zbiera dane o prędkości zespołów, żeby porównać, u którego z zespołów jest ona „najwyższa” i na tej podstawie… przyznać premię i nagrody. Nawet nie będę mówić o losie zespołów z „najniższą” prędkością w tej organizacji.

Co to znaczy zmierzyć ILOŚĆ i po co to w ogóle robić?

Celem mierzenia tego obszaru jest weryfikacja efektywności pracy – czy zwiększamy ilość dostarczonych funkcjonalności produktu, czy mamy z tym jakiś problem. Narzędzia, które za chwilę Ci przedstawię, normalnie można, a nawet warto, połączyć i używać jako zestaw. Osobiście nazywam je koktajlem „Naga prawda”. Korzystanie z tego zestawu przyniesie wiele korzyści dla całego zespołu scrumowego. Ponadto postaram się trzymać fokus na korzyściach dla Product Ownera. Aha, i jeszcze jedno… na pewno spotkasz dużo fanów, którzy nie wyobrażają sobie wytwarzania produktu bez używania poniższych narzędzi, jak i przeciwników, którzy będą twierdzić, że są one bezużyteczne.

Team Velocity [Prędkość zespołu]

Team Velocity jest, cytując Scrum Inc. „kluczowym” narzędziem w Scrumie i jednym z najczęściej używanych w projektach zwinnych. Używa się go do mierzenia ilości pracy, którą zespół deweloperski może wykonać podczas jednego Sprintu.

Przy obliczaniu prędkości powinniśmy wybrać jednostkę wyceny. Bardzo popularną jednostką wyceny prędkości zespołu jest Story Point, ponadto są zespoły estymujące w innych jednostkach liczbowych: punkt, godzina, dzień roboczy, idealny dzień, planeta, itp. Team Velocity przynosi dla Product Ownera wiele korzyści, m.in.:

  • Posiadasz dane o ilości dostarczonej pracy po zakończeniu sprintu;
  • Posiadasz dane o prędkości zespołu w poprzednich iteracjach;
  • Posiadasz dane o minimalnej i maksymalnej prędkości zespołu, czyli znasz “minimum” i “maksimum” zespołu;
  • Posiadasz dane o znormalizowanej prędkości zespołu;
  • Możesz aktualizować elementy Product Wall’u, np. mapę drogową.

Ale… najcenniejsze co daje narzędzie Team Velocity dla PO, to dane empiryczne do przeprowadzenia analizy, planowania rozwoju, prognozowania dostarczania funkcjonalności produktu, wykrycia ryzyka oraz podjęcia decyzji.

Team Velocity

Co jeszcze warto wiedzieć o Team Velocity?

Zwiększenie prędkości

Najczęściej, po każdym sprincie zespół robi się bardziej zgrany, a jego prędkość stopniowo powinna się zwiększać. Zwiększanie prędkości pozwala zespołowi zrobić więcej w tym samym czasie. Stąd właśnie pomysł Jeffa Sutherlanda na tytuł książki „Scrum. Czyli jak robić dwa razy więcej dwa razy szybciej”. Warto jednak pamiętać, że dążenie wyłącznie (!) do zwiększania wskaźnika prędkości, nie zawsze jest rozsądne. Ponieważ nie zawsze wyższa prędkość oznacza dostarczenie większej ilości wartości biznesowej produktu. Opowiadałem o tym w odcinku #2/5 Jak zmierzyć DOSTOSOWANIE.

Prędkość i błędy w oprogramowaniu

Błąd w oprogramowaniu może zostać wykryty na różnych etapach wytwarzania czy używania produktu. Każdy wykryty błąd ma też swój poziom istotności – więcej informacji o tym znajdziesz w odcinku #3/5 Jak zmierzyć JAKOŚĆ.
Twórcy Scruma, w swoich publikacjach i wywiadach zalecają nie wyceniać wykrytego błędu, jeśli jest on częścią Definicji Ukończenia [Definition of Done] historyjki, ponieważ stanowi on część wyceny tej historyjki. Natomiast jeśli jest to znany błąd, to należy nadać mu priorytet w Backlog’u i wycenić. Jeśli z różnych przyczyn, wykryty błąd nie był częścią historyjki, ale został naprawiony w ramach sprintu, to może być uznany jako praca nieplanowana, o której za chwilę, i nie powinien być uwzględniany w prędkości.

“Kto pierwszy, ten lepszy!”

Nie istnieją pojęcia „dobrej” lub „złej” prędkości. Powinniśmy rozumieć, że skala szacowania pracochłonności w zespołach jest różna, dlatego wartości Velocity również są różne. Jeśli dane uzyskane za pomocą narzędzia Team Velocity używasz do czegokolwiek poza planowaniem i prognozowaniem, to oznacza, że używasz niewłaściwych danych do niewłaściwego celu. Dlatego nie powinno się porównywać prędkości zespołów! Zakaz! Nikomu! Ani PO, ani CEO.

Yesterday’s Weather [Wczorajsza Pogoda]

Yesterday’s Weather jest narzędziem, które pozwala w miarę precyzyjnie prognozować ilość pracy na Sprint. Chociaż nie znajdziesz żadnej info o Yesterday’s Weather w Scrum Guide, zdradzę Ci, że jest to jedno z ulubionych narzędzi Jeffa Sutherlanda, w Scrumie.

Idea polega na tym, że zespół scrumowy na podstawie:

  • sumy wyceny zadań zrealizowanych (np. sumy zrealizowanych Story Points’ów) w poprzednim Sprincie (jak widzisz, tu wchodzi w grę przedstawione powyżej narzędzie – Team Velocity);
  • dostępności deweloperów w nadchodzącym sprincie, czyli team capacity;
  • oraz buforu dla nieplanowanej pracy,

może obliczyć ilość pracy na nadchodzący Sprint, czyli obliczyć sumę wyceny zadań zaplanowanych. Jak się chyba domyśliłeś, korzystając z danych Yesterday’s Weather, Product Owner posiada empiryczne dane, które pomagają lepiej zrozumieć możliwości zespołu i precyzyjniej przygotowywać się do planowania Sprintu.

Pobierz szablon Yesterday’s Weather i wypróbuj to narzędzie!!!

Sprint Burndown Chart [Wykres Spalania Sprintu]

Sprint Burndown Chart jest sprawdzonym i niezawodnym narzędziem, które pokazuje, ile pracy zostało wzięte do Sprintu, ile wykonano podczas Sprintu, oraz ile pracy jeszcze zostało. Innymi słowy… z tym narzędziem śledzimy ilość pozostałej pracy w Sprincie, sprawdzamy jak szybko zespół kończy zadania i przewidujemy, kiedy zespół osiągnie cel sprintu.

O wykresie spalania sprintu nie pisał tylko leniwy. Dlatego pozwól, że skupię się tylko na tym, co według mnie warto wiedzieć i pamiętać podczas korzystania z tego narzędzia.

Sprint Burndown Chart

Widoczny dla wszystkich. Bardzo często Sprint Burndown Chart jest nazywany „narzędziem dla zespołu deweloperów”, z którego oni korzystają podczas Daily Scrum. Rzadziej Sprint Burndown Chart nazywają „narzędziem dla zespołu scrumowego”. Ale to wcale nie jest tak. Prawda jest taka, że cel i zakres Sprintu nie są i nie powinny być żadną tajemnicą. Dlatego warto, aby praca nad Sprint backlogiem była widoczna dla wszystkich, czyli dla interesariuszy również. Dobry Product Owner na bieżąco obserwuje Sprint Burndown Chart. Dane z wykresu wykorzystuje np. do oceny sytuacji ze Sprintem, omawiania planów z interesariuszami, przygotowania się do Refinementu lub/i Planowania Sprintu.

Jak prawidłowo czytać wykres Sprint Burndown?

Sytuacja #1: Zgodnie z planem.

Jeśli linia pokazująca wykonaną pracę jest maksymalnie blisko linii trendu i przecina oś poziomą, to możemy stwierdzić, że w ramach sprintu wykonaliśmy wszystkie zadania.

Sytuacja #2: Szybciej niż zakładaliśmy.

Jeśli linia pokazująca wykonaną pracę jest poniżej linii trendu to znaczy, że zakończyliśmy zadania wcześniej niż zakładaliśmy i dlatego warto sprawdzić możliwość wykonania dodatkowej pracy do Sprintu.

Sytuacja #3: Jesteśmy spóźnieni

Jeśli linia pokazująca wykonaną pracę jest powyżej linii trendu to znaczy, że albo zabraliśmy za dużo pracy, albo nie kontynuujemy oczekiwanego tempa, albo jedno i drugie. W takiej sytuacji, na pewno warto o tym porozmawiać podczas Retrospektywy i ustalić plan „naprawczy”.

Sprint Burndown Chart i Sprint Retrospective. Dobrą praktyką jest, w ramach Retrospektywy Sprintu, użycie wykresu spalania Sprintu do przeprowadzenia analizy odnośnie procesu definiowania zakresu prac. Wspominałem o tym powyżej. Za przykład takiego użycia może posłużyć, właśnie, nieplanowana praca. Jeśli np. nieplanowana praca miała miejsce, to wykres to ujawni i będzie okazja, razem z PO, zastanowić się, dlaczego tak wyszło i jak do takich sytuacji nie doprowadzać w przyszłości.

Release Burnup Chart [Wykres Wypalania Releas’u]

No i oliwką w koktajlu „Naga prawda” jest narzędzie Release Burnup. Bardzo przydatny dla Product Ownera wykres, który pozwoli sprawdzać zakres prac, ilość wykonanych zadań, i ilość pracy oraz czasu, która jeszcze została do wykonania. Chociaż w nazwie jest użyte słowo „Release”, możesz spokojnie używać tego narzędzia przy tworzeniu MVP lub nowej wersji produktu. Od razu uprzedzam, że z tego narzędzia można korzystać na kilka sposobów. Aby to uprościć, powiedzmy, że jest klasyczny sposób i kilka zaawansowanych. Tym razem opowiem o klasycznym sposobie, ponieważ te zaawansowane wymagają osobnego odcinka.

Zacznijmy. Oś Y to zakres prac na Release [Release Scope] – suma wyceny wszystkich zadań w ramach Release’u. Linia pokaże czy zakres był stały, czy były dokonane zmiany; czyli czy coś dodawałeś lub wyrzucałeś.

Oś X to liczba Sprintów w ramach Release’u.

Total Completed – suma wyceny zadań zrealizowanych w każdym Sprincie. Na wykresie – linia, która pokazuje ilość dostarczonej pracy.

Forecast Completed – prognoza na przyszłość w oparciu o średnią prędkość w ostatnich trzech sprintach.

Aby łatwiej było to wszystko zrozumieć podaję prosty przykład. Rysunek przedstawia wykres, gdzie Release składa się z 10 Sprintów. Suma wyceny wszystkich zadań w ramach Release’u, czyli Release Scope, to 100 Story Points’ow (Story Point jest wybraną przeze mnie jednostką wyceny prędkości w tym przykładzie).

Za pomocą prostego obliczenia 100SPs/10Sprintów=10SPs/Sprint, obliczyliśmy, że idealna prędkość wynosi 10SPs/Sprint. Uwaga, jeśli w ramach Release’u wartość Release Scope zmieniła się, to idealną prędkość trzeba obliczyć ponownie.

3 Sprinty są za nami, a Total completed wynosi 27 SPs:

  • Sprint #1: 10 SPs;
  • Sprint #2: 12 SPs;
  • Sprint #3: 5 SPs.

Obliczmy średnią prędkość w ostatnich trzech sprintach 10+12+5=27/3 = 9 SPs.

Teraz możemy zrobić prognozę, że jeśli nic się nie zmieni, to przy średniej prędkości 9SPs/Sprint zespół na koniec 10-go sprintu osiągnie tylko 90SPs. I to właśnie jest ten moment, kiedy Product Owner powinien zareagować i podjąć odpowiednie działania…

Release Burnup Chart

To jest prosty przykład, jak za pomocą odpowiedniego narzędzia, można tworzyć prognozy, oparte o dane empiryczne, które pozwalają Product Ownerowi nie tylko reagować w odpowiednim momencie, ale i podejmować lepsze decyzje.

A jakbyś ty postąpił w takiej sytuacji? Co byś polecił interesariuszom: zwiększyć budżet i powiększyć zespół czy może zmniejszyć zakres prac, czyli usunąć coś z Backlog’u?

Zamiast końcówki

Poznałeś skuteczne sposoby jak sprawdzać efektywność pracy poprzez mierzenie ilości dostarczonych funkcjonalności produktu. Możesz teraz łączyć narzędzia tego odcinka z narzędziami z poprzednich odcinków i oceniać nie tylko ilość, ale i jakość pracy. Możesz robić prognozy, oceniać potencjał, pytać użytkowników o ich zdanie o produkcie i zbierać informację zwrotną. Ale to jeszcze nie wszystko… Niebawem finałowy odcinek cyklu „Co mierzy dobry Product Owner?”, a więc, to jeszcze nie koniec.

Podziel się wpisem:

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp
Share on email
Email

O Autorze wpisu:

Zobacz również

Shopping cart

0

No products in the cart.

ZAPYTAJ O SZKOLENIE DEDYKOWANE

ZAREZERWUJ TERMIN SZKOLENIA