Masz 20 elementów w Product Backlogu i tylko 2 tygodnie na najbliższy Sprint. Które wybierzesz?
To pytanie szybko przestaje być proste, gdy jedna funkcjonalność przyniesie firmie dużą wartość, ale wymaga 3 miesięcy pracy, druga ogranicza poważne ryzyko, a trzecia musi zostać wykonana przed konkretnym terminem.
Właśnie w takich sytuacjach przydaje się WSJF – Weighted Shortest Job First.
To metoda priorytetyzacji wykorzystywana w Agile. Pomaga zdecydować, co zrobić najpierw, gdy nie możesz zrobić wszystkiego jednocześnie.
Podstawowy wzór jest prosty:
czyli:
WSJF = koszt opóźnienia ÷ rozmiar pracy
Koszt opóźnienia składa się z trzech elementów:
Cost of Delay = Business Value + Time Criticality + Risk Reduction / Opportunity Enablement
W praktyce oznacza to:
wartość biznesowa + pilność + redukcja ryzyka lub nowe możliwości ÷ rozmiar pracy = priorytet
Im wyższy wynik WSJF, tym wyższy priorytet.
Nie chodzi więc tylko o znalezienie tego, co jest „najważniejsze”. Chodzi o znalezienie pracy, która daje największą wartość w stosunku do wysiłku potrzebnego do jej wykonania.
- Z czego składa się WSJF?
Business Value – wartość biznesowa
Pierwsze pytanie brzmi:
Jaką wartość dla firmy lub użytkownika przyniesie realizacja tego elementu?
Możesz uwzględnić między innymi:
- wzrost przychodów,
- ograniczenie kosztów,
- poprawę obsługi klienta,
- zwiększenie efektywności,
- poprawę jakości,
- realizację celów strategicznych.
Przykład: firma rozwija platformę sprzedażową. Jedna User Story pozwala obsługiwać klientów w dwóch nowych krajach, druga poprawia wygląd panelu administracyjnego.
Obie mogą być potrzebne, ale pierwsza prawdopodobnie ma znacznie wyższą wartość biznesową.
To jednak dopiero początek oceny.
Time Criticality – pilność
Drugie pytanie:
Czy wartość tego elementu spadnie, jeżeli wykonasz go później?
Wyobraź sobie funkcję wspierającą kampanię sprzedażową zaplanowaną za 3 tygodnie. Jeżeli wykonasz ją miesiąc po kampanii, jej wartość może być niewielka.
Z kolei funkcja poprawiająca raportowanie wewnętrzne może być równie użyteczna za miesiąc, trzy miesiące czy pół roku.
Przy ocenie pilności warto sprawdzić:
- czy istnieje konkretny termin,
- czy opóźnienie oznacza utratę wartości,
- czy inni użytkownicy lub zespoły czekają na tę funkcję,
- czy istnieje określone okno rynkowe,
- czy późniejsza realizacja zwiększy koszty.
Risk Reduction / Opportunity Enablement
Trzeci element obejmuje redukcję ryzyka oraz otwieranie nowych możliwości.
Przykładowo zespół może planować wykorzystanie nowej technologii. Niewielkie zadanie polegające na przetestowaniu jej możliwości nie przynosi bezpośrednio przychodu.
Może jednak ujawnić problem, który za dwa miesiące wymusiłby przebudowę dużej części produktu.
Realizując małe zadanie teraz, ograniczasz potencjalnie duże ryzyko.
Podobnie działa Opportunity Enablement. Niektóre zadania nie dają dużej wartości same w sobie, ale umożliwiają realizację kolejnych funkcjonalności.
To również powinno wpływać na priorytet.
- Job Size – dlaczego wielkość zadania ma znaczenie?
Druga część wzoru to Job Size, czyli rozmiar pracy.
Możesz go określać na przykład za pomocą Story Points, czasu, względnej skali złożoności albo innej jednostki stosowanej przez zespół.
Najważniejsze, żeby zachować jedną metodę dla wszystkich ocenianych elementów.
Dlaczego Job Size jest tak istotny?
Bo duża wartość nie zawsze oznacza pierwszy priorytet.
Załóżmy, że masz dwa elementy:
| Element | Cost of Delay | Job Size | WSJF |
| A | 80 | 40 | 2,0 |
| B | 60 | 10 | 6,0 |
Element A ma większy koszt opóźnienia.
Mimo tego B ma znacznie wyższy WSJF.
Dlaczego?
Ponieważ wymaga cztery razy mniej pracy.
Właśnie tutaj kryje się główna idea metody:
Nie pytaj wyłącznie, co jest najbardziej wartościowe. Pytaj, co daje największą wartość w stosunku do rozmiaru pracy.
To szczególnie dobrze pasuje do Agile. Zamiast przez wiele tygodni realizować jedno ogromne zadanie, możesz dostarczyć kilka mniejszych elementów, które szybciej przyniosą użytkownikowi wartość.
- Jak policzyć WSJF na przykładzie Product Backlogu?
Załóżmy, że masz w Product Backlogu pięć elementów:
- integrację z systemem płatności,
- poprawę procesu logowania,
- eksport danych,
- moduł raportowania,
- nowy panel administratora.
Zespół ocenia każdy element w skali 1–10.
| Element | Business Value | Time Criticality | Risk / Opportunity | Cost of Delay | Job Size | WSJF |
| Integracja płatności | 9 | 10 | 8 | 27 | 13 | 2,08 |
| Poprawa logowania | 7 | 8 | 9 | 24 | 5 | 4,80 |
| Eksport danych | 6 | 6 | 5 | 17 | 3 | 5,67 |
| Raportowanie | 8 | 4 | 6 | 18 | 13 | 1,38 |
| Panel administratora | 5 | 3 | 4 | 12 | 8 | 1,50 |
Jak powstają wyniki?
Dla integracji płatności:
9 + 10 + 8 = 27
Następnie:
27 ÷ 13 = 2,08
Dla eksportu danych:
6 + 6 + 5 = 17
Następnie:
17 ÷ 3 = 5,67
W efekcie eksport danych otrzymuje wyższy priorytet niż integracja płatności, mimo że jego Cost of Delay jest niższy.
To bardzo ważna lekcja.
WSJF nie pyta tylko, co stracisz, jeśli czegoś nie zrobisz. Pyta również, ile pracy potrzeba, aby tę wartość uzyskać.
- Jak wykorzystać WSJF w pracy zespołu?
WSJF możesz zastosować bezpośrednio podczas pracy z Product Backlogiem.
Najpierw wybierz elementy, które chcesz ze sobą porównać. Następnie dla każdego oceń:
Business Value
Jaką wartość daje realizacja?
Time Criticality
Jak bardzo ucierpisz, jeśli wykonasz to później?
Risk Reduction / Opportunity Enablement
Jakie ryzyko ograniczasz albo jaką możliwość otwierasz?
Job Size
Jak dużo pracy wymaga realizacja?
Potem obliczasz:
Cost of Delay = BV + TC + RR/OE
oraz:
WSJF = Cost of Delay / Job Size
Na końcu sortujesz elementy od najwyższego do najniższego wyniku.
Warto jednak pamiętać, że liczby nie powinny udawać matematycznej prawdy.
Jeżeli Product Owner przyznaje Business Value = 9, a przedstawiciel biznesu = 5, nie oznacza to, że ktoś popełnił błąd. To sygnał, że warto porozmawiać:
„Dlaczego oceniasz ten element na 9, a nie na 5?”
Różnica może wynikać z innych informacji, perspektyw albo doświadczeń.
I właśnie dlatego WSJF jest czymś więcej niż arkuszem kalkulacyjnym. Porządkuje rozmowę o priorytetach.
Na co uważać?
Nie traktuj WSJF jak automatu, który podejmuje decyzje za Ciebie.
Jeżeli funkcjonalność musi powstać ze względu na bezpieczeństwo, przepisy albo zobowiązanie kontraktowe, jej realizacja może być konieczna niezależnie od wyniku.
Nie próbuj też manipulować wynikiem poprzez sztuczne zawyżanie wartości albo zaniżanie Job Size.
WSJF działa najlepiej wtedy, gdy oceny są wspólne, uzasadnione i oparte na aktualnej wiedzy.
WSJF jako element zarządzania Product Backlogiem
WSJF dobrze uzupełnia pracę z User Stories i Product Backlogiem.
Możesz potraktować cały proces jako prosty ciąg:
User Story → ocena wartości → ocena pilności → ocena ryzyka/możliwości → ocena rozmiaru → WSJF → priorytet → Sprint
To ważne, ponieważ priorytety nie powinny być ustalane raz na początku projektu.
Nowe informacje mogą zmienić Business Value. Zbliżający się termin może zwiększyć Time Criticality. Odkryte zagrożenie może podnieść znaczenie Risk Reduction. Lepsze poznanie rozwiązania może zmienić Job Size.
W efekcie zmieni się również WSJF.
Dlatego priorytety w Agile mogą się zmieniać.
Nie chodzi o to, żeby kurczowo bronić kolejności ustalonej trzy miesiące wcześniej. Chodzi o podejmowanie najlepszych decyzji na podstawie tego, co wiesz dzisiaj.
Jeżeli masz więc 15 elementów w Product Backlogu, nie pytaj wyłącznie:
„Który jest najważniejszy?”
Zapytaj:
„Który element ma obecnie największy koszt opóźnienia w stosunku do pracy potrzebnej do jego wykonania?”
To właśnie pytanie prowadzi Cię do WSJF.
Duża wartość + mały wysiłek = wysoki priorytet.
Mała wartość + duży wysiłek = niski priorytet.
A pomiędzy nimi znajduje się cała przestrzeń do świadomej rozmowy o tym, co naprawdę warto zrobić najpierw.
