Co mierzy dobry Product Owner, odcinek #2/5 Jak zmierzyć DOSTOSOWANIE?

Spis Treści

Co mierzy dobry Product Owner, odcinek #2/5 Jak zmierzyć DOSTOSOWANIE?

Podczas mierzenia i oceniania sytuacji z dostosowaniem, Product Owner może brać pod uwagę wiele wskaźników. Ponieważ jest ich sporo, to nie będę o nich wszystkich opowiadać, lecz skupię się na istotnych. Duże znaczenie dla Product Ownera ma wskaźnik świadczący o dostosowaniu produktu do biznesu. Innym, równie ważnym, jest wskaźnik dostosowania pracy zespołu do celów biznesu.

Relative Return On Investment (Relative ROI), [Relatywny zwrot z inwestycji]

Nie zawsze w produkcie informatycznym da się określić zwrot w wartości monetarnej, czyli w prawdziwych pieniądzach. Dlatego, w organizacjach z podejściem zwinnym, zamiast wartości monetarnej często używa się wartości relatywnej – biznesowej. Jest kilka sposobów na określenie wartości biznesowej, na pewno opowiem o nich w przyszłości.

 

Relative ROI jest tym odpowiednim narzędziem, które pozwoli Ci zmierzyć, jak dużo lub mało wartości biznesowej zostało dostarczone przez zespół podczas iteracji w stosunku do wykonanej pracy.

 

Zanim przejdę do obliczenia, muszę wyjaśnić ważną sprawę. Jak zapewne wiesz, w Scrum Guide nie znajdziesz takich pojęć jak „story point”, „value point” czy „user story”. Są to jednak pojęcia zwinne, i będą one nam za chwilę potrzebne. Pozwolę sobie więc określić wartość biznesową w „value points”, a wykonaną pracę w „story points”.

 

Obliczysz relatywny zwrot z inwestycji wg wzoru: Relative ROI = Earned Business Value / Velocity.

Wynik obliczenia wyraża się w „value points” na „story points”.

A teraz przykład. Po pięciu Sprintach posiadasz następujące dane:

  • Sprint #1: 700 Value Points (VPs), 30 Story Points (SPs)
  • Sprint #2: 1300 VPs, 38 SPs
  • Sprint #3: 1500 VPs, 36 SPs
  • Sprint #4: 1450 VPs, 35 SPs
  • Sprint #5: 1450 VPs, 34 SPs

Po obliczeniu wg podanego powyżej wzoru, mamy wyniki:

  • Sprint #1: 23.3 VPs/SP
  • Sprint #2: 34.2 VPs/SP
  • Sprint #3: 41.6 VPs/SP
  • Sprint #4: 41.2 VPs/SP
  • Sprint #5: 42.6 VPs/SP

O czym to może świadczyć? Powiedzmy, że w Sprincie #1, uzyskano mało wartości biznesowej, ponieważ zespół dostarczył więcej rzeczy back-end’owych, niezbędnych dla produktu, ale „niewidocznych” dla użytkownika końcowego. W Sprincie #2, widzimy wzrost prędkości zespołu, ale nadal „średni” wynik, jeżeli chodzi o wartość biznesową. Natomiast, w Sprincie #3 i #4 prędkość trochę się obniża, ale wzrasta wskaźnik wartości biznesowej. Ponadto, w Sprincie #5 prędkość zespołu jest tylko o 4 Story Points wyższa w porównaniu do Sprintu #1, ale wskaźnik wartości biznesowej jest najwyższy ze wszystkich Sprintów. 

 

Szczerze mówiąc, wyniki te można potraktować na wiele sposobów, dlatego tak ważna jest „wiedza w tle”, czyli rozumienie tego co się działo w rzeczywistości. Można śmiało stwierdzić, że dzięki połączeniu wyników prędkości zespołu i uzyskanej wartości biznesowej widzimy, że nie koniecznym, a nawet nierozsądnym, jest dążenie wyłącznie do zwiększenia wskaźnika prędkości. Nie zawsze wyższa prędkość oznacza wyższą wartość biznesową. Dlatego, dobry Product Owner podczas priorytetyzacji elementów Backlogu, zawsze bierze pod uwagę wartość biznesową.

 

Wcześniej wspominałem, że podczas zarządzania produktem, Product Owner przeprowadza dużo analizy oraz uwzględnia wiele wskaźników. Aby przekonać się o tym, czy podjęte decyzje były właściwe, polecam również skorzystać z narzędzia Net Promoter Score, o którym opowiadałem w odcinku #1 Jak zmierzyć Zadowolenie.

End-to-End Metric (E2E Metric)

Aby sprawdzić czy zakres prac, nad którym pracował zespół, był dostosowany do celów biznesu, a przy okazji świetnie to zwizualizować, proponuję skorzystać z metryki End-to-End. Narzędzie to jest proste i genialne jednocześnie.

 

Pierwszym krokiem jest podział twojego produktu na elementy, np. uwierzytelnienie, autoryzacja, panel użytkownika, monitoring, UX, itd. To są nasze „worki”.

Krokiem drugim jest segregowanie dostarczonych elementów Sprint Backlogu [Sprint Backlog Items] według zdefiniowanych w pierwszym kroku elementów. Aby to lepiej wytłumaczyć, umówmy się, że elementy Sprint Backlogu, są to User Stories [Historyjki użytkownika]. Czyli, „wrzucamy” dostarczone historyjki użytkownika do odpowiednich „worków”.

Trzecim krokiem jest obliczenie ilości „story points” każdego elementu („worka”).  

 

Po wykonaniu tych trzech kroków możesz stworzyć wykres, który pokaże, w co był włożony wysiłek zespołu. Jeszcze dodam, że ten wykres jest bardzo pomocny podczas rozmów z interesariuszami, szczególnie przy zbieraniu wymagań lub negocjowaniu nowego zakresu prac.

Panowie Alistair Croll i Benjamin Yoskovits w książce pt. „Lean Analytics book” napisali, że dobra metryka zmienia nasze zachowanie. Te metryki, zdecydowanie zmieniły moje. Uważasz, że potrafią zmienić Twoje?

Shopping cart

0

No products in the cart.