To będzie post inny niż wszystkie. Przekrojowo spojrzymy na dwie, z pozoru sprzeczne ze sobą rzeczy. Chcę w jasny sposób pokazać dlaczego Product Owner i Story Points nie chodzą ze sobą w parze. Bo nie chodzą.
Product Owner i Story Points
Wstępem do posta mogłaby być opowieść o Product Ownerze, który jest niezastąpiony w Zespole. Robi wszystko, jest SPOC-em (single point of contact) jeśli chodzi o nowe wymagania i Deweloperów w zakresie wyjaśnienia celu realizacji wymagań. Nasz bohater jest osobą, od której wszystko zależy. W tym miejscu z przykrością stwierdzę, że bajka się kończy, a zaczyna się prawdziwe życie.
Sytuacja, o której piszę powyżej, aż nader często występuje w naszych realiach. PO całkiem słusznie jest tą jedną umocowaną osobą, ale w tym umocowaniu tkwi często problem. Mindset kontroli i pilnowania wszystkiego jest silnie zakorzeniony i niestety powoduje określone skutki. Wszystko to powoduje, że ten post nie będzie skupiony na wzorcach a raczej na antywzorcach połączenia PO i Story Pointów.
Product Owner szacujący
Szacowanie elementów Backlogu to czynność, która powinna, a może nawet musi być wykonywana przez Deweloperów. Argumentów za tym jest całe mnóstwo. Pozwólcie, że przytoczę kilka z nich.
Pierwszy to fakt, że to Deweloperzy odpowiedzialni będą za realizację wymagania. Nie będą chcieli zrobić sobie „krzywdy” złą wyceną. Ponadto, osoby wykonujące pracę mają o wiele lepsze pojęcie o tym, ile faktycznie coś zajmie. Inny powód, o wiele bardziej przekonujący to fakt, że ktoś zatrudnił tych ludzi oraz zaufał im, że będą w stanie wykonać wszystkie powierzone im zadania. Po co więc ich wyręczać np. z wyceną?
Jeśli wyceny dokonuje Product Owner możemy spodziewać się, że będzie ona zaniżona. Nie zawsze musi to mieć związek z chęcią upchnięcia, choćby kolanem, jak największej ilości zadań w Backlogu. Czasem może to wynikać z braku holistycznego spojrzenia na system i jego zawiłości. Kolejnym elementem jest brak odniesienia wyceny do całego Zespołu. Szacując jako Product Owner biorę pod uwagę jedynie swój punkt widzenia. A to w zespole jednak tkwi siła i różnorodność.
Product Owner planujący
Planowanie to proces dla Deweloperów. Z przygotowanego, potwierdzonego wcześniej Backlogu wyciągamy tyle jego elementów, ile będziemy w stanie zrealizować w najbliższym Sprincie. To, ile jesteśmy w stanie zrealizować najczęściej jest informacją pochodzącą z poprzednich Sprintów, definiowaną jako Velocity. Czasami jednak zdarza się tak, że Velocity pochodzi od Product Ownera. Zdziwieni?
Może nie jest to podanie konkretnej wartości punktowej wprost. Ale bardzo często Product Owner mówi coś w stylu „to się musi zmieścić w tym Sprincie i już”.
Ta sytuacja powoduje, że jako Zespół jesteśmy przymuszeni do realizacji czegoś, co do końca nam nie pasuje. Mówiąc dosadniej, ktoś zaplanował za Deweloperów Sprint i to wbrew informacjom, które płyną ze statystycznego ujęcia poprzednio zakończonych Sprintów. Przecież Product Owner „wie lepiej”, drogi Zespole. Jest umocowany.
Producr Owner rozliczający
Było o Refinemencie, Planowaniu Sprintu, idźmy więc do końca procesu. Nadchodzi Sprint Review i czas na weryfikację (w niektórych organizacjach rozliczenie) Sprintu.
Czy Product Owner musi dokonywać „rozliczenia” Story Pointów przypisanych do Stories? Czy powinien dokonać urealnienia wyceny, jeśli np. z zaraportowanych godzin wynika mniej? A może powinien to wszystko odpuścić?
Oszacowania w Story Pointach są dla Zespołu. Wycena to nic innego jak względne porównanie ze sobą wymagań znajdujących się w Backlogu, z którego wynika np. ilość pracy, która jest możliwa do zaplanowania na Sprint. Nie żyję jednak na księżycu i wiem, że Story Pointy „gdzieś tam” są przeliczane na żywą gotówkę. Czy muszą? To już temat na zupełnie inny wpis.
W tym chcę zaadresować jedną ważną kwestię. Nawet jeśli Product Ownerze musisz przeliczać Story Pointy na złotówki, spróbuj zrobić to bez udziału Zespołu. Niech Story Points na ich poziomie służą do tego, do czego zostały wprowadzone.
Uwaga na Story Pointy!
Korzystając ze Story Pointów trzeba uważać. Przedstawiłem tylko kilka antywzorców i sytuacji w których faktycznie wykorzystanie „punktów” może skończyć się co najmniej problematycznie. A jest ich o wiele więcej.
W większości powyższych przypadków jasno pokazałem, kto jest beneficjentem wyceny. W większości przypadków jest to Zespół, choć od razu powiem, że nie zawsze tak będzie. Są sytuacje, takie jak mityczne pytanie Interesariusza „To na kiedy to będzie?” czy przytoczona powyżej „konwersja Story Points na pieniądze”, gdzie to nie Zespół będzie czerpał jedyną korzyść.
Uważajmy więc, jak korzystamy ze względnej miary jaką są punkty. Szczególnie kiedy mówimy o przypadku kiedy Product Owner zajmuje się Story Pointami.
