Metoda MoSCoW

Priorytetyzacja jest jednym z podstawowych zadań Product Ownera. Pisaliśmy już o triage, metodzie zaczerpniętej z ratownictwa medycznego, która pozwala na prostą kategoryzację według prostych kryteriów. Dziś dla odmiany opowiemy o metodzie MoSCoW.

 

Po co nam priorytetyzacja?

Przed przejściem do samej metody MoSCoW, zastanówmy się, po co w ogóle dokonujemy priorytetyzacji. Jest ona procesem mającym za zadanie wydobyć najważniejsze na dany moment wymagania. W tym celu najczęściej obieramy punkt widzenia naszego klienta. To właśnie on decyduje, co w chwili obecnej jest dla niego najważniejsze i co ma dla niego najwyższą wartość biznesową. Chociaż nie ukrywajmy, często ten wybór jest dokonywany za delikatną sugestią Product Ownera.

Priorytetyzacja to proces ciągły. Oznacza to, że nie ma formalnego spotkania (np. wydarzenia w metodyce Scrum), podczas którego powinniśmy usiąść i dokonywać priorytetyzacji. Jeżeli zaś chodzi o Scrum, to w każdej chwili może odbyć się Product Backlog Refinement. Dodatkowo, przynajmniej podczas Sprint Review, powinniśmy wspólnie z interesariuszami naszego projektu zastanowić się, co w chwili obecnej przedstawia dla nas najwyższą wartość.

Oczywiście dobry Product Owner nie przyjmie priorytetu wymagania bez zadania pytań typu “Czy faktycznie jest to dla Was teraz najważniejsze?” oraz “Co się stanie, jeśli tego nie zrobimy?”. Jeśli odpowiedź nie będzie jasno wskazywała potrzeby realizacji danego wymagania na wczoraj, PO powinien zasugerować odłożenie funkcjonalności na później.

N chyba, że klient się uprze.

 

Metoda MoSCoW

Istnieje wiele metod 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 wymagania klienta.

Jakie mogą być to kryteria? Istotność produktu projektu dla organizacji, zwrot na inwestycji, potrzeba szybkiej odpowiedzi na ruch konkurencji. Aspektów priorytetyzacji może być naprawdę wiele i wszystko zależy od organizacji, klienta i samego projektu.

Jednym z najczęściej wykorzystywanych sposobów jest metoda MoSCoW. Wymyślona została przez Dai Clegga, a po raz pierwszy użyta w metodyce DSDM (Dynamic Systems Development Method). Nazwa nie ma nic wspólnego ze stolicą Federacji Rosyjskiej, bo MoSCoW to po prostu mnemonik. Duże litery oznaczają poszczególne kategorie Backlogu Produktu:

M – Must have
S – Should have
C – Could have
W – Want / Won’t have (this time)

Metoda zakłada, że każdy element naszego backlogu powinien zostać skategoryzowany poprzez przydzielenie go do jednej z powyższych kategorii. W każdej chwili powinniśmy być w stanie odpowiedzieć na pytanie, co jest dla nas M (Must have), a co tylko C (Could have).

Metoda ta może zostać użyta niezależnie od horyzontu planowania naszego projektu. Możemy ją wykorzystać zarówno do zaplanowania najbliższego Sprintu, jak i kilku Sprintów albo całego wydania. Lista wymagań zawsze zawierała będzie elementy ważne, mniej ważne i te, których nie będziemy realizować (teraz lub nigdy).

 

M/S/C/W – czym właściwie są?

Skoro wiemy już jakie mamy kategorie, przyjrzyjmy się ich znaczeniu w kontekście produktu naszego projektu.

M – Must have to wszystkie wymagania, których implementacja jest konieczna z punktu widzenia końcowego produktu. Przyjęło się, że zestaw wymagań oznaczonych kategorią M powinien utworzyć dobrze nam znane MVP.

S – Should have to te wymagania, które są istotne z punktu widzenia finalnego produktu, jednak w przypadku ich braku możliwe jest zastosowanie dla nich obejścia (ang. workaround). Niekoniecznie znaczy to, że dane obejście będzie łatwe dla użytkownika. Ale jeśli ma taką możliwość, to wymaganie już nie będzie oznaczone jako Must have.

C – Could have – wymagania, które nie są krytyczne czy ważne z punktu widzenia produktu finalnego. Zwykle poprawiają one jakość naszego produktu, ale niekoniecznie dostarczają nowych funkcjonalności i rozwiązań. Z punktu widzenia Zespołu Deweloperskiego realizacja wymagań z tej kategorii powinna zająć niewielką ilość czasu, bo i korzyść dla klienta nie jest znacząca.

Na koniec została kategoria W – Want  / Won’t have. Do niej trafiają takie wymagania, bez których możemy żyć i takie, których po prostu nie zrealizujemy w najbliższej iteracji. Na te elementy Backlogu Produktu nawet nie spojrzymy.

Wymagania z kategorii M powinny stanowić maksymalnie 60% planowanych do wykonania zadań (w określonym horyzoncie czasowym, np. Sprint, bądź wydanie). Wymagania ważne, dla których istnieje obejście (kategoria S) powinny stanowić kolejne 20%, podobnie zresztą jak te oznaczone literą CCould have. Wymagań przypisanych do ostatniej z kategorii (W) nie ujmujemy w planie na najbliższe Sprinty/wydanie.

 

Jak korzystać z metody MoSCoW?

Zastosowanie metody MoSCoW nie wymaga specjalnych umiejętności, ani nawet praktyki. Po zapoznaniu się z mechaniką priorytetyzacji i przedstawieniu jej klientowi, dość łatwo uzyskamy wspólne zrozumienie tego, co jest najważniejsze.

Nie możemy jednak zapominać o zmienności wymagań w czasie. W każdej chwili może pojawić się coś nowego, co spowoduje przesunięcia elementów pomiędzy poszczególnymi kategoriami. Czy to jednak nam przeszkadza?

Wymagania ujęte w Backlogu Productu powinny być stabilne w momencie planowania kolejnej iteracji. To w tym czasie Zespół Deweloperski powinien mieć wiedzę o tym, co jest najważniejsze i czym będzie się w najbliższym czasie zajmował.

A co jeśli coś się zmieni? Po pierwsze, jeśli najważniejsze staje się coś, czego jeszcze nie rozpoznaliśmy, a powinniśmy zaplanować to w bieżącym Sprincie – zastanówmy się nad tym trzy razy. Spróbujmy negocjować z Product Ownerem podział wymagania na mniejsze lub odsunięcie jego realizacji do momentu chociażby zapoznania się z tematem.

A po drugie, pamiętajmy, że realizujemy wymagania zgodnie z priorytetem. Ujarzmienie ich zmienności przy pomocy krótkich iteracji jest jedną z przewag zwinnego podejścia do wytwarzania produktu nad podejściem klasycznym. Mówiąc inaczej – zawsze możemy poczekać do następnego Sprintu.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: