Praca z klientami to trudne zadanie, zwłaszcza jak jest wielu klientów i każdy ma inne wymagania. Użytkownik końcowy potrzebuje nowych przycisków, PM – zrealizowania milestonów  pochodzących z Umowy, a CEO się pyta kiedy koniec projektu. I każdy się pyta: kiedy? 

Pytania 

  1. Jak to wszystko ogarnąć w zmiennym środowisku?  
  2. Jak ułożyć zadania?  
  3. Jak wytłumaczyć zespołowi takie a nie inne wymagania? 
  4. Dlaczego nie robimy tego co było ważne miesiąc temu? 
  5. Jak ustalić wartość dla klienta? 

MoSCow w zadaniu

W takich przypadkach możemy wykorzystać analizę biznesową opartą na metodzie MoSCow, i do każdego zadania dodać oznaczenie jednoliterowe.

Takie oznaczenie od razu sortuje nam listę wymagań – od tych co muszą zostać zrealizowane do tych co mogą być oraz tych co nie powinny być wdrażane w aktualnym momencie. W Product Backlog mogą znajdować się wymagania które na stan dzisiejszy nie są porządane.

Po dokładne wytłumaczenie odwołuję się do wikipedii: https://pl.wikipedia.org/wiki/Metoda_MoSCoW, tutaj opiszę jak wykorzystanie tych czynników wpłynie na przejrzystość priorytetyzacji.

Komunikacja 

W trakcie zbierania wymagań jasno określajmy jakie kryterium spełnia oczekiwania. Często się okazuje, że wszystko Musi być, lecz z doświadczenia wiem, że to nie prawda. PO powinien umieć analizować sytuację tak aby inteligentnie balansować pomiędzy wymaganiami różnych interesariuszy wychwytując te – które przyniosą największą wartość do produktu.  

Jeżeli mamy działającą funkcjonalność, a końcowy użytkownik potrzebuje zmienić lekko design, musimy zdiagnozować czy ta modyfikacja będzie miała większą wartość niż totalnie nowa rzecz. Bardzo często w trakcie dyskusji można dojść do porozumienia, że design powinien wyglądać inaczej, ale bardziej konieczne jest wprowadzenie innego modułu.

Product Backlog 

Z pomocą przychodzi nam Product Backlog – czyli jedno prawdzie źródło wymagań produktu. Poprzez prezentowanie tej listy interesariuszom PO zyskuje pewność w jasności sytuacji – jeden z filarów Scrum – Transparentność. W przypadku oznaczenia każdego zadania jako Must każdy inteligentny interesariusz zobaczy, że aktualna sytuacja jest patowa, i niestety trzeba pójść na kompromis i należy uporządkować listę zupełnie inaczej.

Podsumowanie 

Metoda MoSCoW sama z siebie pozwala na ustalanie priorytetów. W przypadku wielu zadań “Musi być”, należy szukać alternatywnego rozwiązania – spotkanie wszystkich interesariuszy, wspólne podjęcie decyzji – lub też autorytarna decyzja PO, która w Scrum’ie musi być respektowana.

Takie sytuacje nie są komfortowe natomiast musimy ufać Właścicielowi Produktu, że aktualny porządek zadań rzeczywiście odzwierciedla największą wartość rozwojową Produktu – nawet gdy czasem końcowy użytkownik będzie musiał dłużej poczekać na realizację krytycznej dla niego zmiany.