Backlog miał 240 pozycji. Sponsor chciał wszystkiego „na wczoraj", trzech kierowników działów uważało, że ich funkcja jest najważniejsza, a zespół deweloperski miał moc przerobową na jakieś 15 historyjek na sprint. Analityczka, którą obserwowałem, popełniła wtedy klasyczny błąd: usiadła z product ownerem i zaczęli ustawiać priorytety „na czuja" - ten ważny, tamten mniej ważny, ten chyba też ważny. Po godzinie 200 pozycji miało priorytet „Wysoki". Kiedy wszystko jest priorytetem, nic nim nie jest.
Priorytetyzacja wymagań to jedna z tych umiejętności, które oddzielają analityka, który spisuje życzenia, od analityka, który podejmuje decyzje. W tym artykule pokażę Ci dwie najważniejsze techniki - MoSCoW i WSJF - kiedy stosować którą, jak liczyć WSJF poprawnie (bo połowa internetu liczy to źle), oraz jak uniknąć pułapek, które sprawiają, że priorytetyzacja staje się teatrem.
Dlaczego priorytetyzacja wymagań decyduje o losie projektu
Każdy projekt IT działa pod trzema ograniczeniami naraz: czas, budżet i zasoby. Wymagań jest zawsze więcej, niż da się zrealizować. Pytanie nie brzmi „co zbudujemy?", tylko „co zbudujemy najpierw, jeśli czas się skończy?". To pytanie pada zawsze - różnica polega na tym, czy odpowiadasz na nie świadomie na początku, czy w panice trzy dni przed deadline'em.
Priorytetyzacja to nie układanie listy „od najważniejszego do najmniej ważnego". To podejmowanie decyzji o kompromisach: jeśli to wejdzie do zakresu, tamto z niego wypada. Dobra technika priorytetyzacji robi trzy rzeczy: czyni te kompromisy widocznymi, opiera je na jawnych kryteriach i daje interesariuszom wspólny język do rozmowy o trudnych wyborach.
Bez tego wpadasz w jedną z dwóch pułapek. Pierwsza to inflacja priorytetów - wszystko jest „krytyczne", bo nikt nie chce przyznać, że jego funkcja może poczekać. Druga to priorytetyzacja oparta na tym, kto głośniej krzyczy - wygrywa interesariusz z największą władzą, a nie ten z największą wartością do dostarczenia.
MoSCoW - priorytetyzacja przez kategorie
MoSCoW to technika wywodząca się z metodyki DSDM (Dynamic Systems Development Method), spopularyzowana w latach 90. Nazwa to akronim czterech kategorii - duże litery - z dodanymi „o" dla wymowy: Must have, Should have, Could have, Won't have. Zamiast ustawiać wymagania w kolejności, wrzucasz je do jednego z czterech kubełków.
Must have - bez tego produkt nie ma sensu
To wymagania, bez których wdrożenie jest bezwartościowe, niezgodne z prawem albo niebezpieczne. Test jest brutalny: jeśli choć jedno Must have nie wejdzie, czy nadal wypuścimy produkt? Jeśli odpowiedź brzmi „tak, da się żyć" - to nie jest Must have. „Must" oznacza również Minimum Usable SubseT - minimalny zestaw, który tworzy działający produkt.
- Źle: „Eksport raportu do PDF - to Must have, bo szef lubi PDF-y."
- Dobrze: „Rejestracja pacjenta i zapis wizyty w kalendarzu - Must have, bo bez tego system rejestracji wizyt nie rejestruje wizyt."
Should have - ważne, ale nie krytyczne
To wymagania istotne, które boli pominąć, ale produkt zadziała bez nich - choć z gorszym doświadczeniem albo z obejściem (workaround). Klasyczny test: jeśli zabraknie czasu, Should have można przesunąć do następnego wydania bez wysadzania projektu w powietrze.
Could have - miło mieć, jeśli starczy czasu
Wymagania pożądane, o niewielkim wpływie, gdy ich zabraknie. To pierwsza linia tego, co wypada z zakresu, gdy czas zaczyna gonić. Nie traktuj Could have jako „prawie Should have" - to bufor, który celowo poświęcasz, żeby dowieźć Must i Should na czas.
Won't have (this time) - świadomie poza zakresem
Najczęściej ignorowana, a najważniejsza kategoria politycznie. „Won't have" nie znaczy „nigdy" - znaczy „nie w tym wydaniu". Spisanie tego, czego świadomie nie robimy, ucina niekończące się dyskusje i chroni przed scope creepem. Kiedy ktoś za miesiąc zapyta „a gdzie integracja z NFZ?", odpowiedź brzmi: „Won't have w wydaniu 1, ustaliliśmy to 3 marca, jest w rejestrze."
Zasada DSDM, o której mało kto pamięta: Must have nie powinno przekraczać 60% wysiłku w danym wydaniu. Jeśli 90% Twojego backlogu to Must have, nie masz priorytetyzacji - masz listę życzeń z naklejką „pilne".
Jak prowadzić sesję MoSCoW w praktyce
MoSCoW najlepiej robić jako krótki warsztat, nie jako solową pracę przy biurku. Mój sprawdzony przebieg: wypisz wszystkie wymagania na karteczkach, narysuj cztery kolumny (Must, Should, Could, Won't) i poproś interesariuszy o wspólne układanie. Zaczynaj od pytania „co się stanie, jeśli tego nie będzie?" - to ono kategoryzuje, nie „jak bardzo to lubisz". Gdy ktoś chce wrzucić piąte wymaganie do Must, pokaż licznik wysiłku: „Musty mają już 70% mocy zespołu, coś musi zejść do Should". Ta widoczna granica robi za Ciebie najtrudniejszą robotę negocjacyjną.
Ważne: kategoryzacja MoSCoW dotyczy konkretnego wydania w konkretnym czasie, nie wymagania „w ogóle". To samo wymaganie może być Won't have w wydaniu 1 i Must have w wydaniu 3. Dlatego do nazwy kategorii zawsze dopisuję kontekst - „Won't have (wydanie 1)" - żeby nikt nie odczytał tego jako „nigdy".
WSJF - priorytetyzacja przez liczby
WSJF (Weighted Shortest Job First) to technika ze skalowanego Agile (SAFe), oparta na ekonomii teorii kolejek Donalda Reinertsena. Idea: realizuj najpierw to, co da najwięcej wartości w najkrótszym czasie. WSJF nie wrzuca wymagań do kubełków - daje każdemu liczbę, która mówi, w jakiej kolejności je robić.
Formuła WSJF
WSJF = Koszt Opóźnienia (Cost of Delay) / Rozmiar Zadania (Job Size)Im wyższy wynik, tym wcześniej powinno wejść do realizacji. Mianownik to klucz: dwie funkcje o tej samej wartości - robisz najpierw tę mniejszą, bo szybciej uwolni wartość i odblokuje zespół. To właśnie znaczy „weighted shortest job first" - najkrótsze zadanie ważone wartością.
W SAFe Cost of Delay (CoD) jest sumą trzech składowych, każda oceniana w skali względnej (zwykle ciąg Fibonacciego: 1, 2, 3, 5, 8, 13, 20):
Cost of Delay = User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement
WSJF = (User-Business Value + Time Criticality + RR/OE) / Job Size- User-Business Value - ile wartości dla użytkownika i biznesu? Czy klienci tego chcą? Jaki przychód lub oszczędność?
- Time Criticality - czy wartość spada z czasem? Czy jest deadline regulacyjny? Czy konkurencja nas wyprzedzi?
- Risk Reduction / Opportunity Enablement - czy to redukuje ryzyko techniczne lub otwiera przyszłe możliwości (np. fundament pod kolejne funkcje)?
- Job Size - szacowany wysiłek (proxy dla czasu realizacji). Często tożsamy ze story pointami epiku.
Dlaczego oceniamy względnie, a nie w złotówkach
Nie znasz dokładnego CoD w PLN - i nie musisz. WSJF działa, bo oceniasz pozycje względem siebie. Najmniejszą wartość w każdej kolumnie ustawiasz na 1, resztę skalujesz w stosunku do niej. Chodzi o kolejność, nie o precyzję księgową. To najważniejsza różnica wobec NPV czy ROI, które wymagają twardych liczb.
Przykład liczenia WSJF
| Funkcja | Business Value | Time Criticality | RR/OE | CoD (suma) | Job Size | WSJF |
|---|---|---|---|---|---|---|
| Integracja płatności online | 8 | 5 | 3 | 16 | 5 | 3,2 |
| Powiadomienia SMS o wizycie | 5 | 8 | 2 | 15 | 3 | 5,0 |
| Panel statystyk dla zarządu | 8 | 2 | 5 | 15 | 13 | 1,15 |
| Logowanie przez Google | 3 | 2 | 3 | 8 | 2 | 4,0 |
Mimo że panel statystyk ma wysoki Cost of Delay (15), jego WSJF jest najniższy (1,15), bo jest ogromny (Job Size 13). Powiadomienia SMS wygrywają (5,0) - średnia wartość, ale mały rozmiar i wysoka krytyczność czasowa. To jest właśnie sedno WSJF: mały, pilny i wartościowy bije duży i ważny.
Dlaczego mianownik zmienia wszystko
Zatrzymajmy się tu na chwilę, bo to najważniejsza intuicja w całej technice. Wyobraź sobie dwie funkcje o identycznej wartości biznesowej. Pierwsza zajmie zespołowi dwa dni, druga - dwa miesiące. Którą zrobić najpierw? Oczywiście tę dwudniową - bo szybciej uwolni wartość, a potem i tak zostanie czas na drugą. Gdybyś realizował najpierw dwumiesięczną, wartość pierwszej funkcji „czeka" w kolejce przez dwa miesiące, generując koszt opóźnienia każdego dnia. WSJF formalizuje tę intuicję: dzieli wartość przez rozmiar, więc przy równej wartości krótsze zadanie zawsze ma wyższy priorytet. To dlatego technika nazywa się „Weighted Shortest Job First" - najkrótsze zadanie, ważone wartością, idzie pierwsze.
Konsekwencja praktyczna: WSJF naturalnie premiuje rozbijanie dużych epiców na mniejsze kawałki. Epic o Job Size 20 i CoD 15 ma WSJF 0,75. Ale jeśli podzielisz go na cztery niezależne historie po Size 5, z których jedna dostarcza większość wartości (CoD 10), ta jedna ma WSJF 2,0 - i wskakuje na początek kolejki. Dekompozycja to nie tylko higiena backlogu; to dźwignia priorytetu.
MoSCoW vs WSJF - tabela porównawcza
| Kryterium | MoSCoW | WSJF |
|---|---|---|
| Typ wyniku | Kategoria (4 kubełki) | Liczba (ranking ciągły) |
| Pochodzenie | DSDM | SAFe / teoria kolejek Reinertsena |
| Najlepsze do | Ustalenie zakresu wydania, rozmowa z biznesem | Kolejkowanie backlogu, epiki, programy |
| Poziom obiektywizmu | Jakościowy, podatny na „wszystko Must" | Półilościowy, wymusza porównania |
| Uwzględnia rozmiar/wysiłek? | Nie | Tak (w mianowniku - to jego siła) |
| Uwzględnia czas (deadline)? | Pośrednio („Won't have this time") | Tak (Time Criticality) |
| Szybkość użycia | Bardzo szybka, warsztatowa | Wolniejsza, wymaga estymacji |
| Ryzyko nadużycia | Inflacja Must have | Pozorna precyzja, gaming liczb |
| Komunikacja z zarządem | Intuicyjna („to musi być") | Wymaga wyjaśnienia formuły |
Moja praktyczna rada: te techniki się nie wykluczają - uzupełniają. MoSCoW świetnie ustala, co w ogóle wchodzi do wydania (zakres). WSJF świetnie ustala, co robić najpierw w obrębie tego, co wchodzi (kolejność). W realnych projektach używam MoSCoW na poziomie wydania z biznesem, a WSJF na poziomie backlogu z zespołem.
Mini-przykład end-to-end: MediFlow
MediFlow to sieć 12 przychodni, która wdraża system rejestracji wizyt online. Po warsztacie zebraliśmy 9 najważniejszych wymagań na pierwsze wydanie. Pokażę, jak przeszły przez obie techniki.
Krok 1: MoSCoW - co w ogóle wchodzi do wydania 1
| Wymaganie | Kategoria | Uzasadnienie |
|---|---|---|
| Rejestracja konta pacjenta | Must | Bez konta nie ma rezerwacji |
| Wybór terminu i lekarza | Must | Rdzeń produktu |
| Potwierdzenie wizyty e-mailem | Must | Wymóg - pacjent musi mieć dowód rezerwacji |
| Anulowanie/przełożenie wizyty | Should | Da się obejść telefonem do recepcji w wydaniu 1 |
| Powiadomienie SMS dzień przed | Should | Mocno obniża no-show, ale produkt zadziała bez tego |
| Płatność online za wizytę prywatną | Should | Można płacić na miejscu na start |
| Panel statystyk obłożenia dla zarządu | Could | Wartościowe, ale nie pilne |
| Logowanie przez Google | Could | Wygoda, jest e-mail jako alternatywa |
| Integracja z systemem NFZ | Won't (this time) | Złożone prawnie, wydanie 2 |
Decyzja zakresowa: wydanie 1 = wszystkie Must + tyle Should, ile zmieści się w 6 sprintach. NFZ świadomie poza zakresem - zapisane, żeby nikt nie wracał z pytaniem.
Krok 2: WSJF - w jakiej kolejności robić Should have
Musty są oczywiste (fundament, idą pierwsze). Ale które Should robić najpierw, skoro nie wiadomo, czy wszystkie się zmieszczą? Tu wchodzi WSJF:
| Should have | BV | TC | RR/OE | CoD | Size | WSJF |
|---|---|---|---|---|---|---|
| Powiadomienie SMS dzień przed | 8 | 5 | 2 | 15 | 3 | 5,0 |
| Anulowanie/przełożenie wizyty | 5 | 5 | 3 | 13 | 5 | 2,6 |
| Płatność online | 8 | 3 | 3 | 14 | 8 | 1,75 |
Kolejność: SMS → anulowanie → płatność. Powiadomienie SMS wygrywa, bo redukuje no-show (realny ból biznesu - puste sloty to stracony przychód), jest tanie w realizacji i ma wysoką krytyczność czasową. Płatność online, mimo wysokiej wartości, jest duża - ląduje na końcu kolejki Should. Gdyby czas się skończył po 5 sprincie, płatność elegancko spada do wydania 2, a produkt i tak dowozi sensowną wartość.
Najczęstsze błędy przy priorytetyzacji
1. Wszystko jest „Must have"
Najpowszechniejszy grzech MoSCoW. Test ratunkowy: zapytaj „jeśli to wypadnie, czy wciąż wdrożymy produkt?". Jeśli pięć osób mówi „tak" przy dziesięciu pozycjach - masz dziesięć Should albo Could, nie dziesięć Must. Trzymaj się limitu ~60% wysiłku na Must.
2. Liczenie WSJF jako Value × Size zamiast Value / Size
Widziałem to w prawdziwych zespołach. Ktoś mnoży zamiast dzielić - i nagle największe, najdroższe epiki lądują na szczycie kolejki, bo „mają najwyższy wynik". To odwraca cały sens techniki. Job Size jest w mianowniku. Mały job przy tej samej wartości zawsze wygrywa.
3. Mylenie Job Size z wartością
Job Size to wysiłek (proxy czasu realizacji), nie wartość i nie złożoność biznesowa. Funkcja może być prosta technicznie, a bardzo wartościowa - wtedy ma wysoki WSJF i to dobrze.
4. Priorytetyzacja bez zespołu deweloperskiego
Estymacja Job Size bez deweloperów to zgadywanie. Analityk zna wartość, zespół zna koszt. WSJF wymaga obu. Rób to wspólnie - najlepiej na refinemencie backlogu.
5. Priorytetyzacja raz i na zawsze
Priorytety się starzeją. Pojawia się nowy regulator, konkurencja wypuszcza funkcję, zmienia się strategia. WSJF i MoSCoW to nie tabliczki kamienne - przeglądaj je co iterację albo przy każdej istotnej zmianie kontekstu.
6. Mylenie priorytetu z kolejnością prac
„Must have" nie znaczy „robimy najpierw". Czasem trzeba zrobić techniczny fundament (Should albo nawet enabler), zanim ruszysz Musty. MoSCoW mówi co wchodzi do zakresu; sekwencję sprintów ustalasz osobno, uwzględniając zależności.
Inne techniki, które warto znać
MoSCoW i WSJF to dwie najważniejsze, ale nie jedyne metody priorytetyzacji. Dobry analityk ma w plecaku kilka, bo różne sytuacje wołają o różne narzędzia.
Kano - priorytetyzacja przez satysfakcję klienta
Model Kano patrzy na wymagania z perspektywy tego, jak wpływają na zadowolenie użytkownika. Dzieli funkcje na trzy główne typy: podstawowe (oczekiwane - ich brak frustruje, ale obecność nie zachwyca; np. że rejestracja w ogóle działa), wydajnościowe (im więcej, tym lepiej - np. szybkość ładowania) i zachwycające (delighters - nieoczekiwane funkcje, które budują lojalność, np. inteligentne podpowiadanie wolnego terminu u tego samego lekarza). Kano świetnie uzupełnia MoSCoW: pomaga zrozumieć, dlaczego coś jest Must (bo to wymaganie podstawowe), a coś Could (bo to delighter).
Value vs Effort (macierz wartość-wysiłek)
Najprostsza wizualna technika: rysujesz kwadrat z osiami „wartość" i „wysiłek" i wrzucasz wymagania w cztery ćwiartki. Quick wins (wysoka wartość, niski wysiłek) robisz najpierw. Big bets (wysoka wartość, wysoki wysiłek) planujesz świadomie. Fill-ins (niska wartość, niski wysiłek) robisz, gdy zostanie czas. Money pits (niska wartość, wysoki wysiłek) odpuszczasz. To w gruncie rzeczy uproszczony, wizualny kuzyn WSJF - idealny na szybki warsztat z biznesem, który nie chce liczyć formuł.
Stack ranking - twarda kolejka
Czasem najprostsze rozwiązanie jest najlepsze: ustaw wszystko w jednej, twardej kolejce od 1 do N, bez remisów. Brzmi prymitywnie, ale wymusza najtrudniejsze rozmowy - bo nie da się powiedzieć „oba są tak samo ważne". Product ownerowie często stosują stack ranking na szczycie backlogu (najbliższe 1-2 sprinty), a MoSCoW/WSJF głębiej.
Którą technikę wybrać?
Krótki przewodnik decyzyjny z mojej praktyki:
- Warsztat z biznesem, ustalasz zakres MVP, mało czasu → MoSCoW. Szybkie, intuicyjne, świetne do rozmowy z nietechnicznymi interesariuszami.
- Masz duży backlog epiców i pytanie „co robimy najpierw" → WSJF. Wymusza porównania i bierze pod uwagę rozmiar.
- Projekt regulowany z twardym deadline'em prawnym → WSJF z naciskiem na Time Criticality, ale Musty regulacyjne wprost oznacz w MoSCoW.
- Skalowany Agile, wiele zespołów, planowanie programu → WSJF (to jego natywne środowisko w SAFe).
- Realny projekt → oba. MoSCoW dla zakresu wydania, WSJF dla kolejności wewnątrz wydania.
FAQ - priorytetyzacja wymagań
Czy MoSCoW i WSJF można łączyć?
Tak, i to jest najlepsza praktyka. MoSCoW ustala, co wejdzie do wydania (zakres), WSJF - w jakiej kolejności realizować pozycje wewnątrz tego zakresu. Używaj MoSCoW z biznesem na poziomie wydania, WSJF z zespołem na poziomie backlogu.
Jaka jest dokładna formuła WSJF?
WSJF = Cost of Delay / Job Size. Cost of Delay to suma trzech składowych: User-Business Value + Time Criticality + Risk Reduction/Opportunity Enablement. Każdą oceniasz względnie (zwykle ciągiem Fibonacciego). Im wyższy wynik, tym wcześniej realizujesz.
Co zrobić, gdy interesariusz upiera się, że wszystko jest Must have?
Zadaj pytanie kontrolne: „Jeśli to jedno wypadnie, czy wciąż wypuszczamy produkt?". Jeśli odpowiedź brzmi „tak", to nie Must have. Przypomnij też zasadę, że Must have nie powinno przekraczać ~60% wysiłku w wydaniu - to argument, którego trudno podważyć.
Czy WSJF nadaje się do małych projektów?
Dla kilkunastu pozycji WSJF bywa nadmiarowy - MoSCoW albo proste głosowanie wystarczą. WSJF błyszczy przy dużych backlogach epiców, gdzie intuicja zawodzi, a różnice w rozmiarze są duże.
Kto powinien przeprowadzać priorytetyzację?
Product owner odpowiada za decyzję, ale analityk biznesowy ją facylituje i dostarcza danych: wartość biznesową, kontekst regulacyjny, krytyczność czasową. Job Size estymuje zespół deweloperski. Priorytetyzacja to praca zespołowa, nie solowa.
Podsumowanie
Priorytetyzacja to nie sortowanie listy - to podejmowanie decyzji o tym, czego świadomie nie zrobimy. MoSCoW daje Ci szybki, czytelny język do ustalania zakresu z biznesem. WSJF daje Ci dyscyplinę liczb, która wynagradza małe, pilne, wartościowe rzeczy zamiast wielkich i efektownych. Najsilniejsi analitycy, których znam, używają obu - i nigdy nie pozwalają, żeby wszystko stało się priorytetem.
Jeśli chcesz przećwiczyć priorytetyzację na realnym backlogu, zacznij od dobrze napisanych wymagań - bo nie da się priorytetyzować mglistych życzeń. Zajrzyj do naszego poradnika jak pisać dobre User Stories oraz jak pisać kryteria akceptacji, a po więcej technik wydobywania wymagań do 10 technik elicytacji wymagań. Definicje pojęć znajdziesz też w naszym słowniku analityka.