Priorytetyzacja to zadanie Product Ownera. Jest wiele sposobów na ułożenie wymagań w backlogu, ale ostateczne zdanie zawsze należy do PO. Nie musi jednak robić tego „na czuja”, bo może posiłkować się technikami i metodami. Jedną z takich metod jest MoSCoW.
Metoda MoSCoW
Metoda MoSCoW to proste narzędzie do priorytetyzowania wymagań projektu bądź Elementów Backlogu Produktu. Jej nazwa nie ma nic wspólnego z rosyjską stolicą, ale pochodzi od pierwszych liter angielskich słów poszczególnych jej kategorii. Must have (Musimy), Should have (Powinniśmy), Could have (Możemy), Won’t have (Nie będziemy).
Kategorie te oznaczają priorytet, tak więc rzeczy, które musimy zrobić (Must have) będą na pewno ważniejsze niż te, które tylko możemy zrobić (Could have). Tu czai się pierwsza pułapka – metoda MoSCoWnie ułoży za nas backlogu w kolejności. Co najwyżej podzieli go na cztery części.
I w sumie moglibyśmy powiedzieć, że powyższe wyjaśnienie wystarczy. Warto jednak dodać, że w ten sposób możemy priorytetyzować zarówno pojedynczy Sprint, jakieś wydanie albo i cały backlog.
Kategorie MoSCoW
MoSCoW jest prosty, ale kryję się w nim pewne niuanse. Przejdźmy więc przez poszczególne kategorie i przyjrzyjmy im się bliżej.
Wymaganie, które musimy zrobić to Must have. Bez tych elementów projekt czy produkt nie miałby sensu. Są one priorytetem numer jeden i można powiedzieć, że wszystkie razem stanowią pewne MVP.
Wymagania z kategorii Should have są ważne, ale nie tak krytyczne jak „Must have’y”. Mogą poczekać, jeśli nie ma wystarczających zasobów lub czasu na ich realizację. W ich przypadku możliwe jest zastosowanie dla nich obejścia. Może to być wykonanie pewnych czynności ręcznie bądź w skrajnie niewygodny sposób, ale jest ono możliwe. Bez „Should have’ów” nie zginiemy, ale może być przykro bądź wstyd.
Could have to elementy, które dobrze by było zrealizować, ale nie są niezbędne. Często są to pomysły, które mogą dodać dodatkową wartość, jeśli będzie na to czas i środki. Tutaj też są wszystkiego rodzaju udogodnienia i ułatwienia poprawiające jakość. Raczej nie będzie tu całych funkcjonalności, ale bardziej jakieś dodatki.
Ostatnia kategoria bywa nazywana Won’t have, a czasami Want. Są to te wymagania, bez których możemy żyć. Są one jasno odrzucane w obecnej fazie (np. wydaniu). Mogą być rozważane w przyszłości, ale nie są teraz potrzebne.
Jak korzystać z metody MoSCoW?
Zgodnie z najlepszymi praktykami Must have nie powinny stanowić więcej niż 60% rozważanego czasu. Jeśli chcemy spriorytetyzować wymagania na najbliższe 10 Sprintów, to „Must have’ów” powinno w nich być na nie więcej niż 6 Sprintów. Ma to sens, bo dajemy sobie bufor na nieprzewidziane rzeczy, w tym na opóźnienia.
Jeżeli do Must have’ów dodamy Should have’y to nie powinniśmy wykraczać poza 80% naszych możliwości. Wszystkie trzy kategorie (M, S, C) nie mogą przekraczać 100% naszej normy, liczonej np. jako Velocity.
Zabierając się do używania metody MoSCoW „by the book”, w pierwszym kroku powinniśmy oznaczyć wszystkie wymagania jako „Won’t have”. Następnie, dla każdego z nich powinniśmy uzasadnić, dlaczego powinno ono otrzymać wyższy priorytet. Dla każdego „Must have” zapytajmy „Co się stanie, jeśli tego nie zrobimy?” Jeśli już istnieje możliwość obejścia braku funkcjonalności, to nie jest ona „Must have”. Działa tu też zasada przechodniości, jezeli „Must have” jest zależne od innego wymagania, to ono również jest „Must have”.
Po co priorytetyzacja?
Istnieje bardzo dużo sposobów priorytetyzacji Backlogu Productu. Każdy Product Owner ma możliwość ułożenia elementów listy wymagań według dowolnych kryteriów, jakie uzna za stosowne. Ważne, aby odzwierciedlały one potrzeby klienta, wartość produktu lub… cokolwiek, co uznaliśmy za ważne. Na przykład Cel Produktu.
Przed użyciem metody MoSCoW, zastanówmy się, po co w ogóle dokonujemy priorytetyzacji. Zwykle robimy to, bo chcemy ułożyć plan albo wyłonić najważniejsze w danym momencie wymagania. Patrzymy przy tym z różnych punktów widzenia – najczęściej oczami klienta bądź użytkownika, czasami jednak naszymi korporacyjnymi planami bądź według rynku. Nie ma to większego znaczenia dla samej metody, bo koniec końców decyzję i tak podejmuje Product Owner.
Pamiętajmy tylko, że priorytety się zmieniają, a priorytetyzacja to proces ciągły. Nie ma formalnego momentu, podczas którego powinniśmy usiąść i dokonywać priorytetyzacji, chociaż zwykle robimy to przygotowując się do Planowania. W Scrumie robimy to przynajmniej podczas Sprint Review oraz Planowania Sprintu. Żadne Product Owner nie ograniczy się tylko i wyłącznie do tego.
I tu wracamy do pytań sugerowanych przez Metodę MoSCoW. „Czy faktycznie jest to dla Was teraz najważniejsze?” oraz „Co się stanie, jeśli tego nie zrobimy?” to nieodłączne elementy procesu priorytetyzacji. I jeśli okaże się, że bez czegoś jesteśmy w stanie żyć, to nie mówmy, że jest to „Must have”. 60% to wcale nie jest tak dużo.
