Czym jest metoda priorytetyzacji Musi Powinno Może Nie Będzie?
Nasze działania powinny wyrażać nasze priorytety, a Musi Powinno Może Nie Będzie to świetny szablon retrospektywy sprintu, który pomaga zespołom zidentyfikować te priorytety, aby zapewnić ciągłe dostarczanie wartości tam, gdzie jest ona najbardziej potrzebna. Mając to na uwadze, jest to podejście, które dobrze współgra z procesami i frameworkami zwinnymi, biorąc pod uwagę jego koncentrację na dostarczaniu wartościowych rzeczy w pierwszej kolejności. Jest to również świetny pomysł na retrospektywę sprintu Scrum, ponieważ oferuje właścicielowi produktu mechanizm wejścia w buty klienta i spojrzenia na produkt z jego perspektywy. Opracowana w latach 90. przez Dai Clegga, metoda MSCW zyskała znaczenie w zwinnym zarządzaniu projektami i analizie biznesowej. Zapewnia ustrukturyzowany sposób organizowania zadań w cztery odrębne kategorie: Musi mieć (krytyczne), Powinno mieć (ważne), Może mieć (pożądane) i Nie będzie mieć (nie priorytet).
Format Musi Powinno Może Nie Będzie
Musi
Rzeczy, które musimy zdecydowanie zrobić.
To są niepodlegające negocjacjom wymagania, które są krytyczne dla sukcesu. Podczas omawiania elementów 'Musi', zachęcaj uczestników do rozważenia prawdziwych blokad lub niezbędnych elementów, bez których projekt by się nie powiódł. Zachęcaj zespół do rygorystycznego podejścia do tego, co kwalifikuje się jako 'Musi', aby uniknąć inflacji priorytetów.
Powinno
Rzeczy, które powinniśmy zrobić.
To są ważne funkcje lub wymagania, które dodają znaczącą wartość, ale nie są krytyczne dla uruchomienia. Pokieruj zespołem w rozważaniu elementów, których brak byłby bolesny, ale nie zatrzymałby funkcjonowania projektu. Skup się na elementach o wysokiej wartości, ale niższej pilności.
Może
Rzeczy, które moglibyśmy zrobić.
To są pożądane funkcje, które byłyby miłym dodatkiem, jeśli pozwolą na to zasoby. Pomóż zespołowi zidentyfikować ulepszenia, które poprawiłyby rozwiązanie, ale nie są niezbędne. Te elementy często są dobrymi kandydatami do przyszłych iteracji lub wydań.
Nie Będzie
Rzeczy, których nie zrobimy.
To są elementy wyraźnie odrzucone dla tej iteracji lub projektu. Zachęcaj do szczerej dyskusji o funkcjach, które, choć potencjalnie wartościowe, nie są zgodne z obecnymi celami lub ograniczeniami. Pomaga to utrzymać fokus i zarządzać oczekiwaniami.
Kiedy stosować tę retrospektywę?
- Podczas planowania nowego projektu lub inicjatywy i potrzeby ustalenia jasnych priorytetów
- Podczas sesji udoskonalania backlogu, aby zorganizować i priorytetyzować żądania funkcjonalności
- Gdy występują ograniczenia zasobów i trzeba podejmować trudne decyzje dotyczące zakresu
- Na spotkaniach z interesariuszami, aby uzgodnić oczekiwania dotyczące rezultatów i harmonogramów
Sugerowane pytania dotyczące lodołamaczy
- Jaka była najtrudniejsza decyzja dotycząca priorytetów, którą musiałeś podjąć w projekcie?
- Gdybyś mógł dostarczyć tylko trzy funkcje w obecnym projekcie, jakie by to były i dlaczego?
Pomysły i wskazówki dotyczące spotkania retrospektywnego
- Ogranicz elementy 'Musi' do maksymalnie 60% wszystkich wymagań, aby zachować realistyczny zakres
- Regularnie przeglądaj i aktualizuj kategoryzację w miarę zmiany potrzeb biznesowych i ograniczeń
- Używaj timeboxingu podczas dyskusji, aby zapewnić efektywne podejmowanie decyzji
- Dokumentuj uzasadnienie kategoryzacji, aby zachować jasność i spójność
- Angażuj wszystkich kluczowych interesariuszy w proces priorytetyzacji, aby zapewnić ich poparcie
- Uwzględniaj zależności między elementami podczas przypisywania kategorii