Główna zaleta Story Points w Scrumie
Jeśli Story Points są miarą czasu (wysiłku), dlaczego nie można po prostu używać godzin lub dni? Po co w ogóle potrzebne są Story Points?
Główny powód dla Story Points
Ocenianie Product Backlog Items za pomocą Story Points ma kilka dobrych powodów. Istnieje jednak jeden główny powód, który w zupełności wystarczy, aby uzasadnić stosowanie Story Points. Mianowicie ma to coś wspólnego z królem Henrykiem I, który panował od 1100 do 1135 roku. Przed jego panowaniem istniała miara długości „jard", która była równa odległości od wyciągniętego kciuka do nosa danej osoby. Wyobraź sobie, jakie zamieszanie to powodowało. W końcu odległość ta była różna dla każdej osoby. Pewnego dnia król Henryk postanowił, że jard ma zawsze wynosić tyle, ile odległość od jego wyciągniętego kciuka do jego nosa.
To było praktyczne dla niego. Ale i dla wszystkich innych, bo teraz była ustalona jednostka miary. Dla każdej pojedynczej osoby oznaczało to, że jeden jard (długość ramienia króla) był może odrobinę dłuższy lub krótszy niż własne ramię. W ten sposób wszyscy mieli jednolitą miarę długości.
Względne szacowanie za pomocą Story Points
Z Story Points jest tak samo. Podobnie jak angielskie jardy, Story Points pozwalają członkom zespołu o różnych kwalifikacjach wspólnie dokonać względnej oceny.
Można też użyć innego przykładu: Wyobraź sobie, że chcesz wybrać się na jogging z kimś. Biegniesz w dość szybkim tempie, a ta druga osoba jest wolniejsza. Wskazujesz na trasę i mówisz: „Chodźmy tą trasą, zajmie nam to 30 minut." Twój partner do biegania za każdym razem, gdy biegł tą trasą we własnym tempie, potrzebował 60 minut i mówi Ci o tym. Wtedy się kłócicie: „30". „60". „30". „60". Ale to was nie posuwa do przodu. Możecie pójść na kompromis i ustalić 45 minut. Byłoby to jednak najgorsze, co moglibyście zrobić, bo teraz zrobilibyście ocenę, która nie odnosi się do żadnego z was. Zamiast zgadzać się na 45 minut, dyskutujecie więc znowu: „30". „60". „30". „60".
W pewnym momencie mówisz do swojego partnera do biegania: „Okay, ta trasa ma 5 km. Pokonam ją w 30 minut." A on odpowiada: „To prawda, trasa ma 5 km. Ale mnie zajmuje to 60 minut."
Problem polega na tym, że oboje macie rację. Ty naprawdę możesz pokonać trasę w 30 minut, a Twój partner w 60 minutach. Wspólna ocena nie zadziała, ponieważ oboje pracujecie lub biegniecie różnym tempem.
Gdy jednak używa się bardziej abstrakcyjnej jednostki miary – tu kilometry – można dojść do porozumienia. Zgadzacie się, że trasa ma 5 kilometrów. Jedyna różnica polega na tym, ile czasu każda osoba na to potrzebuje.
Podsumowanie – konsens przy różnych prędkościach pracy
Story Points służą temu samemu celowi. Dzięki nim osoby o różnych umiejętnościach i różnych prędkościach pracy mogą dojść do konsensusu. Zamiast wolniejszego i szybszego biegacza – jak w powyższym przykładzie – można wyobrazić sobie dwóch programistów o różnej produktywności:
Podobnie jak biegacze, programiści mogą zgodzić się, że dana User Story otrzymuje 5 Story Points (zamiast 5 km). Szybszy z dwóch programistów może myśleć, że to dla niego tylko jeden dzień pracy. Wolniejszy natomiast uważa, że potrzebuje na to dwóch dni. Mogą się jednak zgodzić na 5 Story Points, ponieważ liczba punktów przy pierwszej Story może być jeszcze całkowicie dowolna.
Od tej pierwszej oceny można następnie wyprowadzić wszystkie kolejne dla następnych Stories. Jeśli szybszy z dwóch przy następnej Story zakłada, że potrzebuje na to dwóch dni (dwa razy tyle co na pierwszą), to przyznaje tej Story 10 punktów. Wolniejszy programista myśli, że potrzebuje czterech dni (też dwa razy tyle co na pierwszą) – i on też przyznaje jej 10 punktów.
I tak Story Points – podobnie jak długość ramienia w historii o królu Henryku – pomagają różnym osobom dojść do konsensusu.
Niniejszy tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.
Tworzenie strategii produktu
Planning Poker
=> Właściwy moment na Planning Poker
