Skip to content

Story points. O co chodzi z tymi punktami

Często jestem świadkiem trudności, z jaką przychodzi zespołom przestawienie się na metody szacowania oparte o jednostki względne, jakimi są story points. „Przyjmujemy, że jeden punkt to dzień, tak?” — słyszę często podczas sesji estymacyjnych.

Niesłusznie zakładamy, że szacowanie w story pointach polega na zamianie dni czy godzin na jakieś abstrakcyjne punkty, które nadal mają odzwierciedlać czas.

Tak nie jest. Chociaż celem szacowania nadal pozostaje odpowiedź na pytanie, ile czasu coś zajmie, to zamiast od razu odpowiadać na pytanie o czas, powinniśmy najpierw oszacować rozmiar pracy do wykonania. Następnie, biorąc pod uwagę naszą wydajność, będziemy mogli określić czas potrzebny na wykonanie zadania.

Jeżeli zadaniem jest np. pokonanie trasy z Gdańska do Warszawy, to zanim powiemy, ile czasu nam to zajmie, określamy rozmiar pracy do wykonania — długość trasy wyrażoną w kilometrach. To oczywiście duże uproszczenie, bo oprócz samej długości trasy uwzględnimy też jej złożoność: liczbę obszarów zamieszkałych po drodze, długość wyremontowanych dwupasmowych odcinków i odcinków starej jednopasmówki.

Następnie określamy wydajność — średnią prędkość wyrażoną w kilometrach na godzinę. Tutaj także oprócz możliwości samego środka transportu uwzględnimy inne czynniki, takie jak natężenie ruchu, warunki pogodowe, umiejętności kierowcy, czas potrzebny na przerwy.

Warto podkreślić dwie kwestie: (1) długość trasy pozostaje taka sama niezależnie od tego, kto, czym, jak i kiedy będzie ją pokonywał; (2) większa trudność jest w szacowaniu prędkości niż długości trasy.

Dopiero wynik działania matematycznego (rozmiar/wydajność) to jest ten czas potrzebny na jej pokonanie.

W wytwarzaniu oprogramowania często nieświadomie idziemy na skróty i zamiast oszacować osobno rozmiar pracy i osobno wydajność, próbujemy od razu oszacować czas potrzebny na wykonanie zadania.

Powód jest banalny: brak sensownej jednostki pracy w wytwarzaniu oprogramowania i używanie jednostek czasu — mitycznych osobogodzin czy osobodni.

O ile możemy zmierzyć drogę do przejechania w kilometrach, ściany do pomalowania w metrach kwadratowych, ładunek do rozładowania w tonach, to w czym zmierzyć oprogramowanie? W dodatku nieistniejące, które dopiero ma powstać?

Brak jednostki nie wyklucza jednak możliwości pomiaru. Na rysunku poniżej zostały umieszczone trzy koła. Nie znamy dokładnej powierzchni każdego z nich, ale na oko widać, że B jest większe od A około dwa razy, a C — 4 do 6. Nie potrzebujemy bezwzględnej jednostki, żeby móc porównać ze sobą dwa obiekty i określić ich relatywny rozmiar. Jeżeli kołu A przypiszemy wartość 1, to możemy uznać, że B ma rozmiar 2, a C — 5.

Koło B jest dwa razy większe niż A, a C pięć razy większe.

Koło B jest dwa razy większe niż A, a C pięć razy większe.

Wśród zwinnych zespołów popularnym sposobem formułowania wymagań są historyjki użytkownika (user stories). Porównując je ze sobą możemy określić relatywny rozmiar jednej historyjki w stosunku do drugiej przypisując im punkty (story points). Oczywiście, ma to zastosowanie nie tylko w stosunku do historyjek użytkownika, ale też do wymagań sformułowanych w dowolnej innej formie.

Pojawia się pytanie, jakie cechy porównywanych ze sobą wymagań uwzględniać. Tutaj głosy są podzielone: jedni twierdzą, że chodzi o wysiłek, jaki należy włożyć, inni zaś, że o złożoność wymagań. Ja staram się uwzględniać stopień pewności klienta co do swoich wymagań, stopień zrozumienia wymagań przez zespół, złożoność wytwarzanego rozwiązania, czy praca będzie wykonywana samodzielnie czy przez kilku różnych specjalistów, wysiłek, jaki trzeba będzie włożyć, ryzyko.

Im większe obiekty, tym większa musi być między nimi różnica, żeby móc ją dostrzec i określić, który z obiektów jest rzeczywiście większy i o ile. Na rysunku poniżej wyraźnie widoczna jest różnica między kołami A i B czy B i D, ale już nie między D i E. Wydają się one być porównywalne ze sobą i nawet jeśli dostrzeżemy, że D jest ciut mniejsze od E, to trudno jest określić, o ile. (W rzeczywistości D = 7 × A, E = 8 × A.)

Koła D i E wyglądają na porównywalne, chociaż D = 7 × A, a E = 8 × A.

Koła D i E wyglądają na porównywalne, chociaż D = 7 × A, a E = 8 × A.

Dlatego wiele technik szacowania relatywnego jako jednostki przyjmuje liczby Fibonacciego: 1, 2, 3, 5, 8, 13 itd. Nie potrzebujemy rozgraniczać historyjek np. 11, 12 i 13-punktowych, bo przy tej skali oraz uwzględniając błąd szacowania to nie ma większego znaczenia. Ciąg Fibonacciego to oczywiście nie jedyna możliwa skala. Równie dobrze jako jednostki sprawdzą się rozmiary ubrań: S, M, L.

Na tym właśnie polega relatywne szacowanie w story pointach. Punkty odzwierciedlają rozmiar pracy, a nie czas potrzebny do jej wykonania.

Liczba ukończonych story pointów w jednostce czasu (np. w tygodniu czy sprincie) to nasza wydajność określana mianem prędkości zespołu (velocity). Mając oszacowane wymagania w Backlogu Produktu i znając naszą prędkość możemy prognozować czas zakończenia danego zakresu prac.

Podsumowując:

  • Zamiast szacować czas potrzebny na wykonanie pracy, skup się najpierw na oszacowaniu jej rozmiaru.
  • Nie szacuj rozmiaru pracy w jednostkach czasu; użyj jednostek względnych.
  • Wydajność (prędkość) mierz empirycznie.
  • Czas zakończenia prac prognozuj na podstawie oszacowanego rozmiaru pracy do wykonania oraz mierzonej ciągle wydajności.

Powiązane wpisy:

Categories: Estymacja.

Comment Feed

4 komentarze

  1. Cóż, choć o tym samym usłyszałem i w pracy, rozpoczynając przygodę ze sprintem, to tak samo bym i zrozumiał z tego artykułu. :) Bardzo przejrzyście, zrozumiale napisany artykuł. :)

  2. „Punkty odzwierciedlają rozmiar pracy, a nie czas potrzebny do jej wykonania” – słyszę to powtarzane jak mantrę, ale nikt nie potrafi zdefiniować czym trudność/rozmiar/wysiłek/etc jest, gdy pytam o punkt odniesienia dla „5”.
    Nie jest złożonością – podstemplowanie miniona kartek ma złożoność niewiele większą niż jednej.
    Jako metryka do porównywania niepodobnych zadań, czas jest odpowiedni, jako że stanowi nasz budżet. Ale czas względny – „tyle co XYZ, chyba, a XYZ miało 5”.
    Po ustabilizowaniu „team velocity” punkty też dobrze przekładają się na bezwzględny czas. Po prostu staramy się o tym nie myśleć.
    Czy dobrze to rozumiem?

  3. @mamert punkty oceniają coś co moim zdaniem można określić jako „pracochłonność”. Problem pojawia się w rozumieniu tego właśnie terminu.
    Jeżeli zadanie jest bardzo pracochłonne to nie oznacza, że musi być trudne. Przykładowo: ręczne przepisanie 2000 adresów mailowych do bazy jest bardzo pracochłonne chociaż banalnie proste, ale przygotowanie jednego algorytmu, którego efektem jest wyliczenie jednego wskaźnika, ale jego wymyślenie jest bardzo karkołomne też jest bardzo pracochłonne.
    Inny przykład: postawienie jednego wysokiego biurowca, a 50 domków jednorodzinnych, pracochłonność jest taka sama – czytaj duża, czytaj wysoka wartość w story pointsach :)

  4. Dawid Dziwalski6 maja 2016 @ 09:32

    @Jarek bardziej złożoność niż pracochłonność.
    W moim przypadku najpierw podchodzimy do określenia złożoności zadania biorąc pod uwage m.in.:
    – Poziom trudności zadania
    – Wielkość zadania
    – Zakres wiedzy na temat zadania i/lub systemu
    – Dostęp do źródła informacji
    – Zakres pracy – Analiza, Development, Testy

    W momencie oszacowania złożoności próbujemy określić czas realizacji przy uwzględnieniu m.in.:
    Dyspozycja zespołu (dni wolne, dodatkowe zadania, etc.)
    – Zmienna/Stała dyspozycja środowiska
    – Złożoność zadań (Story Points)
    – Story Points zrealizowane w poprzednim sprint
    – Współzależność, powiązanie zadań -> powinny być – niezależne
    – Spotkania (Planning, Review, Retrospection, DailyScrum, Grooming)

    Pzdr ;)



Some HTML is OK

or, reply to this post via trackback.