Story point – rewolucja w estymacji zadań? cz. 2

Kiedy nie używać user story points?

Widząc wiele korzyści jakie niesie ze sobą zmiana podejścia do estymacji, można przypuszczać, że story points są lepsze od estymacji czasowych. Moim zdaniem nie jest to prawdą, tak samo jak Scrum nie zawsze jest najlepszym sposobem realizacji projektu. Dlaczego? Ponieważ są to różne metody. Tak jak śrubokręt nie jest ulepszoną wersją młotka, tak samo punkty nie są lepszą wersją dni roboczych. I choć można wbijać gwóźdź śrubokrętem, a śrubę wkręcać młotkiem, to ten styl pracy nie przyniesie spektakularnych efektów.

Kiedy story points nie sprawdzi się tak dobrze jak man days?

Duża rotacja w zespole

Jeśli rotacja w zespole jest bardzo duża, to prędkość i dokładność estymat w story point będzie zawsze w fazie kalibracji. Popularny pogląd mówi, że osiągnięcie wiarygodnych danych na temat prędkości w zespole zajmuje ok. 3-4 sprinty. Jeżeli co miesiąc mamy jakąś zmianę w składzie zespołu, wówczas osiągnięcie oczekiwanej dokładności jest znacznie utrudnione.

Mały zespół

Kiedy mamy do czynienia z zespołem jedno- lub dwuosobowym, wówczas nie ma sensu szacować pracy na podstawie abstrakcyjnych wartości. Możemy zebrać bardzo dokładne dane czasowe. Dodatkowo, przy małych zespołach korzyści ze stosowania Scruma nie ujawniają się w sposób wystarczający. Ilość komunikacji w zespole dwuosobowym jest zbyt mała, aby wykorzystać do tego zadania framework.

Krótki, powtarzalny projekt

Niekiedy mamy do czynienia z krótkimi projektami dotyczącymi powtarzalnej, nieskomplikowanej czynności np. instalacji łatki na kolejnych środowiskach w różnych krajach. Oczywiście każda realizacja może być inna i mogą wystąpić nieprzewidziane sytuacje. Jeśli jednak w 99% przypadkach możemy określić czas wdrożenia, to szacowanie w story pointach traci swoje zalety.

Brak znajomości zwinnych metod zarządzania

Wdrażanie sposobu szacowania na story pointy w zespole wymaga pewnego wyczucia i dojrzałości w metodach zwinnego zarządzania. Jeżeli przygodę z tą estymacją zaczniesz od dużej wyceny całego projektu, może się okazać, że to zadanie zbyt ambitne. Prawdopodobne są wówczas małe “oszustwa” (przeliczanie story points na dni) lub bardzo niedokładna estymacja.

Różne kompetencje

Jeśli zespół składa się z kilku osób o zupełnie odmiennych umiejętnościach np.: naukowiec, programista, inżynier maszyn, to znalezienie wspólnego punktu odniesienia może być bardzo trudne. Nie jest to niemożliwe, lecz na początku będzie wymagało więcej czasu niż w zespole o umiejętnościach z pokrewnych dziedzin. Dodatkowo może się okazać, że każdy ze specjalistów pracuje we własnym zakresie, w izolacji – wówczas określenie wspólnego story pointa staje się jeszcze trudniejsze.

Z powyższymi  przykładami można dyskutować, jednak moim celem jest pokazanie, że nie ma idealnej metody szacowania pracy i story points też nią nie są. Przy realizacji projektu każdorazowo należy się zastanowić, które narzędzia w określonych warunkach sprawdzą się lepiej.

Imperatyw zwinności

Obecnie realnym problemem w świecie zarządzania projektami jest podejście ortodoksyjne, skupione na bezrefleksyjnej implementacji Scrum Guide lub innego źródła. Co gorsza, każdy instrument “tradycyjnego” zarządzania projektami jawi się wówczas jako zły, przestarzały i niewłaściwy. Moim zdaniem, 17 stronicowy podręcznik, w przypadku Scrum Guide – stanowiący wprowadzenie do Scrum, nawet jeśli napisany bardzo generycznie nie pokrywa szczególnych przypadków. Tak samo sytuacja wygląda w przypadku innych książek, kursów, podcastów itp. Spotkałem się nawet z określeniami, że Scrum Guide to Biblia. Dostrzegając oczywiście celową przesadę, mimo wszystko, uważam że to szkodliwe podejście, cechujące osoby mniej pewne swojej wiedzy z obszarów poza wąsko rozumianym Scrumem.

Rolą Scrum Mastera lub Project Managera jest umiejętne dostosowanie dostępnych narzędzi do projektu, a nie używanie jednej metody jako panaceum, niezależnie od przypadku. Warto także przypomnieć, że akurat w przypadku story point, nie wynika on wprost ze Scrum Guide i jest koncepcją, która powstała później.

Wartość kierującego projektem widać jedynie wtedy, kiedy potrafi dostosować narzędzia do odpowiedniego celu, nie kierując się osobistymi sympatiami czy chęcią wykazania swojej głębokiej wiedzy w danym obszarze.

Podsumowując, techniki używane przy estymacji, tak samo jak każdy inny element metodyki projektowej powinny być dostosowane do warunków, typu oraz dojrzałości organizacji. Nie jest sztuką wdrażanie czegoś na siłę, kosztem jakości, przejrzystości projektu, a także morali zespołu. Planując swoje podejście do projektu, warto mieć na uwadze powyższą listę okoliczności, które same w sobie nic jeszcze nie przesądzają, ale powinny zachęcić do głębszego przemyślenia wybranej drogi.

W następnym artykule omówię zagadnienie ścieżki krytycznej (Critical Path) względem estymowania w story points. Jest to kwestia łącząca zwinny świat z często występującym oczekiwaniem po stronie biznesu.