MoSCoW to metoda priorytetyzacji, która dzieli wymagania jednego wydania na cztery grupy: Must have (musi być), Should have (powinno być), Could have (może być) i Won’t have this time (nie tym razem). Służy do ustalenia, co zespół gwarantuje w terminie, a co odpadnie jako pierwsze, gdy zabraknie czasu. Działa pod jednym warunkiem: grupa Must ma z góry ustalony limit.
Metoda MoSCoW: co oznaczają cztery kategorie
Metoda pochodzi z podejścia DSDM, a jej opis utrzymuje Agile Business Consortium. Litery „o” w nazwie nic nie znaczą, ułatwiają tylko wymowę.
| Kategoria | Znaczenie | Pytanie kontrolne |
|---|---|---|
| Must have | bez tego wydanie nie ma sensu, jest niezgodne z prawem albo niebezpieczne | Czy bez tej pozycji wydanie trzeba by odwołać? |
| Should have | ważne, ale nie niezbędne: brak jest dotkliwy, a produkt nadal działa, czasem z tymczasowym obejściem | Czy użytkownik poradzi sobie inaczej przez jedno wydanie? |
| Could have | pożądane, o mniejszym wpływie: pierwsze do usunięcia, gdy termin jest zagrożony | Ilu użytkowników zauważy brak? |
| Won’t have this time | uzgodnione jako poza zakresem tego wydania | Czy wszyscy zainteresowani wiedzą, że tego nie będzie? |
Kategorie dotyczą konkretnego wydania albo etapu, a nie produktu w ogóle. Pozycja z grupy Won’t have w marcu może być Must have w czerwcu.
Ile pracy może trafić do Must have
DSDM zaleca, by pozycje Must have zajmowały nie więcej niż 60% planowanego nakładu pracy, a Could have około 20%. Pozostałe 20% to Should have. Ta proporcja jest sednem metody: Could have i część Should have tworzą zapas, z którego zespół rezygnuje, gdy szacunki okażą się zbyt optymistyczne. Termin i grupa Must pozostają wtedy nienaruszone.
Bez limitu MoSCoW zamienia się w listę życzeń z etykietami. Jeśli Must zajmuje 90% pojemności zespołu, każde opóźnienie oznacza przesunięcie terminu albo cięcie rzeczy nazwanych niezbędnymi.
Jak przeprowadzić priorytetyzację MoSCoW krok po kroku
- Ustalenie ram. Termin wydania i pojemność zespołu w osobodniach albo punktach są znane przed rozmową o priorytetach.
- Wycena pozycji. Każda pozycja backlogu ma choćby zgrubne oszacowanie. Bez niego nie da się sprawdzić limitu 60%. Samą listę pozycji można wcześniej wyprowadzić z mapy procesu, którą daje warsztat Event Storming.
- Wspólne kryteria. Zespół spisuje, co kwalifikuje pozycję do Must: wymóg prawny, bezpieczeństwo, zobowiązanie w umowie, brak możliwości wykonania głównego zadania.
- Przypisanie kategorii. Decyduje jedna osoba odpowiedzialna za produkt, po wysłuchaniu sprzedaży, wsparcia i zespołu technicznego.
- Sprawdzenie proporcji. Jeśli Must przekracza 60%, pozycje wracają do dyskusji albo są dzielone na mniejsze.
- Zapisanie Won’t have. Lista rzeczy poza zakresem trafia do wszystkich zainteresowanych, z informacją, kiedy temat wróci.
Przykład: wydanie modułu w produkcie B2B
Przykładowy zespół rozwija system do obsługi zleceń serwisowych i planuje wydanie modułu fakturowania. Ma 100 osobodni do terminu.
| Kategoria | Pozycje | Nakład |
|---|---|---|
| Must have | wystawienie faktury z zamkniętego zlecenia, poprawne stawki VAT, eksport do systemu księgowego używanego przez klientów, uprawnienia dla roli księgowej | 58 osobodni |
| Should have | faktury korygujące, wysyłka faktury e-mailem z systemu | 22 osobodni |
| Could have | własny szablon wydruku, zbiorcze fakturowanie wielu zleceń | 20 osobodni |
| Won’t have this time | faktury w walutach obcych, integracja z bramką płatności | poza wydaniem |
Faktury korygujące budzą spór: księgowość uzna je za niezbędne. Pytanie kontrolne rozstrzyga sprawę. Przez jedno wydanie korektę da się wystawić w systemie księgowym, więc istnieje obejście i pozycja trafia do Should have. Jeśli szacunki okażą się zaniżone o 15 osobodni, zespół rezygnuje z pozycji Could have i wydaje moduł w terminie.
Dlaczego większość pozycji trafia do Must
To najczęstszy sposób, w jaki metoda zawodzi. Przyczyny są zwykle trzy.
- Brak limitu. Jeśli Must nie ma górnej granicy, zaklasyfikowanie pozycji jako niezbędnej nic nie kosztuje.
- Brak zaufania do kolejnych wydań. Interesariusze, którzy nauczyli się, że „później” oznacza „nigdy”, bronią miejsca w Must. Pomaga data przy każdej pozycji Won’t have i dotrzymywanie jej.
- Nikt nie ma głosu rozstrzygającego. Gdy każdy dział oznacza własne tematy, wynik jest sumą interesów zamiast priorytetu. Decyzja należy do jednej osoby odpowiedzialnej za produkt.
Kiedy MoSCoW nie wystarcza
MoSCoW grupuje pozycje, ale nie ustawia ich w kolejności. Dwie pozycje Should have są w tej metodzie równe, choć jedna może dotyczyć stu klientów, a druga trzech. Metoda nie mówi też, czy dana funkcja w ogóle jest potrzebna: klasyfikuje listę, którą ktoś wcześniej ułożył. Jeśli lista wynika z założeń, a nie z rozmów z użytkownikami, staranna priorytetyzacja porządkuje niewłaściwe rzeczy. Listę dobrze jest wcześniej zestawić ze ścieżkami użytkownika, które pokazuje user flow produktu.
Metoda sprawdza się przy stałym terminie i stałym zespole: przed wydaniem, przy definiowaniu zakresu pierwszej wersji produktu (o czym więcej we wpisie o MVP) i przy przygotowaniu wyceny. Do układania roadmapy na kilka kwartałów potrzebne są dodatkowo kryteria wpływu i kosztu. Miejsce priorytetyzacji w całym projekcie pokazuje wpis o tym, jak przebiega proces wdrażania oprogramowania.
MoSCoW w pracy Squares
Stosujemy MoSCoW przy planowaniu sprintów i przygotowywaniu wycen, żeby zamawiający widział, co jest gwarantowane w terminie, a co stanowi zapas. Zakres i kolejność prac ustalamy z zespołem klienta podczas usługi Warsztat produktowy. Gdy w firmie brakuje osoby z głosem rozstrzygającym, tę rolę obejmuje Lider produktu na godziny.
Najczęstsze pytania
Co oznacza skrót MoSCoW?
Skrót pochodzi od czterech kategorii priorytetu: Must have, Should have, Could have i Won’t have this time. Małe litery „o” dodano wyłącznie dla łatwiejszej wymowy i nie mają znaczenia. Pisownia wielkimi i małymi literami podkreśla, które litery są skrótem. Metoda wywodzi się z podejścia DSDM, a jej aktualny opis publikuje organizacja Agile Business Consortium.
Ile wymagań może być w kategorii Must have?
DSDM zaleca, by pozycje Must have zajmowały nie więcej niż 60% nakładu pracy przewidzianego na dane wydanie, a Could have około 20%. Liczy się nakład, nie liczba pozycji. Pozostała część tworzy zapas, z którego zespół rezygnuje przy opóźnieniu, dzięki czemu termin i zakres niezbędny pozostają bez zmian.
Czym różni się Should have od Could have?
Brak pozycji Should have jest dotkliwy i zwykle wymaga tymczasowego obejścia, na przykład ręcznej czynności po stronie użytkownika. Brak pozycji Could have zauważy mniej osób i nie wymaga obejścia. W praktyce Could have to pierwsze pozycje usuwane z zakresu, gdy termin jest zagrożony, a Should have zespół stara się dostarczyć w całości.
Czy Won’t have oznacza rezygnację z funkcji?
Nie. Pełna nazwa kategorii to Won’t have this time, czyli „nie tym razem”. Pozycja jest uzgodniona jako poza zakresem bieżącego wydania i może wrócić w kolejnym. Spisanie tej listy jest równie ważne jak lista Must, ponieważ ustala oczekiwania sprzedaży, wsparcia i klientów, zanim zaczną się prace nad wydaniem.
