Punkty opowieści

Punkty historii to jednostka względnego szacunku, używana do wyrażania rozmiaru danego zadania w porównaniu z innymi zadaniami, a nie czasu potrzebnego na jego wykonanie w godzinach lub dniach. Zespół przypisuje punkty poprzez porównanie z ukończonymi już elementami odniesienia, a skumulowane punkty dostarczane w każdej iteracji stanowią podstawę do prognozowania, ile przyszłej pracy będzie można zmieścić.

Abstrakcja istnieje, ponieważ ludzie szacują względny rozmiar bardziej wiarygodnie niż bezwzględny czas trwania. Zapytani o to, ile czasu coś zajmie, estymatorzy opierają się na optymistycznych założeniach, pomijają przerwy i poprawki oraz konsekwentnie generują dane zaniżone. Zapytani o to, czy jeden element jest większy od drugiego, ci sami ludzie są znacznie bardziej dokładni. Punkty wykorzystują tę asymetrię, rejestrując porównanie i pozwalając, aby obserwowany przepływ dostarczył konwersji na czas.

Punkty mają odzwierciedlać połączenie objętości, złożoności i niepewności, a nie tylko nakład pracy. Niewielka zmiana w nieznanym kodzie o niejasnych wymaganiach może być znacząca niż rozległa zmiana w dobrze znanym obszarze. Zespoły, które redukują punkty do wartości zastępczej na godziny, tracą ten wymiar i odtwarzają problemy z szacowaniem, których ta technika miała unikać.

Miara ta ma charakter lokalny, co jest najczęściej naruszaną cechą w praktyce. Punkty są kalibrowane względem elementów referencyjnych danego zespołu i odzwierciedlają kontekst, bazę kodu i skład tego zespołu. Porównywanie sumy punktów między zespołami jest zatem bezcelowe, a wykorzystanie prędkości jako miary produktywności w zespołach niezawodnie prowadzi do wzrostu szacunków, ponieważ motywacją jest uzyskanie wyższej oceny za tę samą pracę.

To samo zniekształcenie pojawia się w zespole, gdy celem staje się prędkość. Zespół poproszony o zwiększenie prędkości może to zrobić natychmiast, szacując ją bardziej hojnie, a wynik się poprawia, bez żadnych zmian. Ponieważ metryka jest łatwa do manipulowania i została zaprojektowana jako pomoc w planowaniu, a nie jako miara wydajności, jej wykorzystanie w raportowaniu wydajności niweczy jej użyteczność w stosunku do jej rzeczywistego celu.

Szacowanie wiąże się z realnymi kosztami, które zasługują na wnikliwą analizę. Sesje udoskonalania i planowania pochłaniają znaczną ilość czasu zespołu, a w przypadku pracy z w miarę spójnym rozkładem wielkości korzyści z prognozowania w porównaniu z prostym liczeniem elementów są niewielkie. Zespoły stosujące metody bez szacowania zliczają ukończone elementy i prognozują na podstawie historycznej przepustowości, co często jest równie dokładne i znacznie tańsze. To, czy szacowanie jest opłacalne, jest zasadnym pytaniem, a nie herezją.

Ponowna kalibracja jest konieczna zawsze, gdy elementy odniesienia przestają być reprezentatywne, co zdarza się wraz z dojrzewaniem bazy kodu, zmianą składu zespołu lub zmianą charakteru pracy. Zespoły, które przez lata stosują pierwotną skalę, odkrywają, że ich punkty opisują kontekst, który już nie istnieje, a wynikające z tego prognozy dryfują, a nikt nie potrafi zidentyfikować przyczyny.

Punkty pozostają przydatne w ujawnianiu rozbieżności podczas szacowania. Gdy członkowie zespołu przypisują bardzo różne wartości temu samemu elementowi, dyskusja, która następuje później, zazwyczaj ujawnia, że ​​inaczej rozumieli wymaganie lub że jedna osoba jest świadoma komplikacji, a druga nie. Taka rozmowa jest często warta więcej niż wynik, co stanowi argument za kontynuowaniem dyskusji i pragmatycznym podejściem do arytmetyki.

Ponieważ technika ta działa jedynie jako pomoc w planowaniu w ramach jednego zespołu, jej wartość zależy wyłącznie od tego, jak organizacja w nim działająca wykorzystuje wyniki. W praktyce szacowanie jest ustalane w ramach rozwój produktów, a gdy nad jednym produktem pracuje kilka zespołów, koordynacja jest lepiej realizowana poprzez zarządzanie zależnościami i pomiar przepływu w obrębie dział produktów niż poprzez próby normalizacji szacunków pomiędzy zespołami.