Jaki jest najlepszy sposób oszacowania punktów historii w scrum?

Podoba mi się sposób planowania pokera na początku każdego projektu, który umożliwia porównywanie i omawianie szczegółów każdej historii ze sobą.

Jednym z problemów, które zauważyłem, jest to, że wraz z upływem czasu i gdy zdobywasz więcej doświadczenia w dziedzinie problemowej, masz tendencję do głosowania mniejszej liczby punktów za każdą historię, tj. Historię, która na początku była warta 5 lub 8 projektu może być teraz wart 3.

Jak uniknąć lub rozwiązać ten problem w najlepszy możliwy sposób? Czy istnieje lepszy sposób oszacowania? Czy historie powinny pozostać niezmienione, czy te punkty historii spadają w porządku?

Nie sądzę, że to duży problem.

Są dwie oczywiste rzeczy, które mogą to powodować. Jednym z nich jest niewielka deflacja punktów. Drugi polega na tym, że Twój zespół jest coraz szybszy. (Mam nadzieję, że to ten drugi!)

Tak czy inaczej, to nie powinno być nic wielkiego. Dwoma głównymi zastosowaniami prędkości są ustalenie, ile pracy należy podjąć w następnej iteracji, oraz przybliżone oszacowanie dat dostawy dla większych kawałków pracy. Żadnemu z nich nie szkodzi stopniowo zmieniająca się prędkość. Rzeczywiście, jeśli poprawiona prędkość pochodzi z poprawiania się, twoje nowe liczby przedstawiają dokładniejszy obraz zdolności zespołu.

Jeśli prędkość zmienia się zbyt szybko dla wygody, wówczas jedną z odpowiedzi są kanoniczne historie. Przejdź przez ostatnie kilka miesięcy, wybierając 3 historie, które reprezentują poziomy punktów, których używasz. Połóż je na ścianie, na której dokonujesz oszacowań. Następnie, jak oceniasz, użyj ich jako porównania z historią, z którą masz do czynienia. To powinno zmniejszyć zarówno dryf, jak i zmienność szacunków.

Zasadniczo nie jest to naprawdę duży problem, ponieważ większość tych rzeczy wyjdzie na pranie. Ogólnie rzecz biorąc, jawna manipulacja wynikami szacunków będzie negatywna dla procesu. Szacowanie punktów opowieści działa najlepiej, gdy zespoły nie odrywają wzroku od piłki - szacujesz względną złożoność opowieści w porównaniu do innych opowieści i dopóki masz dostęp do informacji historycznych o ukończonych opowiadaniach, prawdopodobnie zobaczysz, jak wszystko się ułoży w dłuższej perspektywie. Oto miejsce, w którym spójność zespołu przynosi korzyści, ponieważ zespół ostatecznie ustali metody i historie referencyjne w celu oszacowania historii.

Deflacja punktów fabularnych może być łagodnym problemem, ponieważ w miarę zmniejszania się zakresu ocen punktowych zaczynasz tracić informacje na temat dostrajania prędkości, a kompresja może mieć negatywne skutki w szacowaniu długości dostarczania długoterminowego wydania planowanie (o ile zamierzasz pomnożyć błędy wprowadzone przez kompresję wszystkich swoich historii do wąskiego zakresu). Ogólnie rzecz biorąc, chcesz, aby wyniki zwiększonej prędkości ze względu na wiedzę specjalistyczną były wyrażane jako przyjmowanie większej liczby punktów historii, a nie obniżanie szacunków. Sposobem na walkę jest ciągłe odwoływanie się do wcześniej ukończonych szacunków i upewnianie się, że zawsze szacujesz złożoność. Nigdy nie określaj, jak długo myślisz, że coś zajmie, po prostu porównaj ogólną trudność historii w porównaniu z poprzednimi. Pozwolić' powiedzmy, że masz aplikację obsługującą platformy mobilne i musisz przenieść się na inną. Czy jest podobny do poprzedniego portu? Trudniej, ponieważ platforma ma gorsze oprzyrządowanie? Łatwiej, bo masz lepszy debugger? To powinno poinformować twoje szacunki, a nie fakt, że ten port prawdopodobnie będzie jechał szybciej, ponieważ twoje zespoły radzą sobie dobrze w szacunkach. Skoncentrowanie się na złożoności powinno pomóc rozwiązać ten problem, o ile istnieje.