Zarządzając projektem bez względu na stosowane podejście (klasyczne czy agile), zawsze dążymy do pełnego zrozumienia wymagań klienta i doprecyzowania z nim priorytetów wykonania. Z doświadczenia wiadomo, że nie jest to stan który szybko udaje się osiągnąć. Mimo tego, że się staramy często na koniec okazuje się, że nie przynosimy klientowi określonej wartości biznesowej albo dostarczamy coś innego niż klient sobie pierwotnie życzył. 
Wobec powyższych problemów w pierwszej kolejności musimy skupić się na dobrej definicji wymagań. Tu z pomocą przychodzą nam techniki definicji wymagań, między innymi sprawdzona technika user stories/historyjek użytkownika, itp. Mając jasno sprecyzowane wymagania potrzebujemy drugiego parametru czyli priorytetu wykonania. Określenie priorytetu wykonywania prac jest potrzebne nie tylko na styku klient dostawca ale również jest cenną informacją dla zespołu. Mając wytyczone priorytety zespół wie co w danej chwili jest najistotniejsze do wykonania, w jakiej kolejności itemy mają być implementowane oraz które itemy mogą nie zostać dostarczone jeśli będzie wywierana presja na zespół lub zaistnieją inne nieprzewidziane wcześniej zdarzenia które wpłyną na pracę zespołu.
Odpowiadając na pytanie jaka metoda wspiera proces priorytetyzacji wymagań?? Odpowiadam, metoda wywodząca się z DSDM (ang. Dynamic Software Development Method) -> MoSCoW.

Akronim MoSCoW rozwija się następująco: 

• Must have – lista itemów które muszą zostać dostateczne zanim wersja produktu zostanie wypuszczona do klienta. Minimalny zakres funkcjonalności, aby nowa wersja była użyteczna
• Should have – lista itemów które nie są krytyczne do tego aby wypuścić nową wersją, ale są ważne z punktu widzenia użytkownika i mogą mu przynieść określone korzyści
• Could have – lista itemów które można potencjalnie wdrożyć przy niewielkim nakładzie czasu i zasobów, z tej listy jako pierwsze mogą być usunięte itemy jeśli czas oddania wersji jest zagrożony bądź opóźniony
• Would have/Won’t have – lista itemów które nie zmieściły się na daną iterację, prawdopodobnie będą dostarczone kiedyś w przyszłości w ramach kolejnych wersji produktu, nie muszą zostać dostarczonew najbliższej wersji

Literki 'o’ w akronimie są dodane tylko po to aby można było sformułować skrót, celowo zapisane małymi literami pokazują brak istotnego znaczenia.

Metoda daję informację które itemy muszą zostać zrobione najszybciej, jako pierwsze, które będą robione kolejno a które mogą być zrobione kiedyś w przyszłych wersjach jak znajdziemy na to czas. Porównując metodę MoSCoW do zwykłego numerowania itemów od 1 do n, należy zauważyć iż słowa przypisane wymaganiom znaczą więcej i zawężają dyskusję do tego co jest ważne w danej chwili. Itemy z przypisanym priorytetem 'Must have’ powinny upewniać zespół o tym że buduje wartościowe funkcjonalności mające przełożenie na realną wartość biznesową. Lista tych itemów przypisana na iterację nie jest negocjowalna i musi zostać dostarczona. Dlatego należy uważać aby na zakres iteracji nie wchodziły tylko itemy o priorytecie 'Must have’, wówczas nie mamy elastyczności która pozwala nam na zmianę zakresu. Poza itemami must have zespół powinien starać się dostarczyć jak najwięcej itemów should have. Pozostałe 'Could have’ mogą być dostarczone ale nie muszą ponieważ nie mają istotnego wpływu na sukces iteracji. Itemy 'Would have’ zostały ustalone zklientem iż nie zostaną dostarczone.
Podsumowując, technikę MoSCoW możemy stosować do ustalania priorytetu implementacji nowych funkcjonalności jaki i poprawek błędów. Ale aby dostarczać nowe wersje naszego produktu zgodnie z realnymi potrzebami klienta niezbędna jest nieustanna współpraca z nim. To klient jest drieverem i musi dawać priorytety na bieżąco które to odzwierciedlą jego realne potrzeby biznesowe.