Che cos'è il metodo di prioritizzazione Must Should Could Won't?
Must Should Could Won't, meglio noto come MoSCoW, divide il lavoro in quattro gruppi: ciò che dovete assolutamente fare, ciò che dovreste fare, ciò che potreste fare se c'è tempo e ciò che questa volta non farete. Usato come retrospettiva, porta il team a concordare apertamente le priorità per il prossimo sprint o rilascio, con tutti presenti. Dai Clegg ha sviluppato il metodo in Oracle negli anni '90 ed è diventato una parte standard del project management agile e della business analysis, in particolare nel DSDM. Le categorie sono Must have (critico), Should have (importante), Could have (desiderabile) e Won't have (non questa volta). Si adatta bene ai metodi di lavoro agili perché mette al primo posto il lavoro di maggior valore. Offre inoltre al product owner un modo strutturato per guardare il backlog dal punto di vista del cliente: se un cliente ne noterebbe la mancanza al lancio, probabilmente è un Must. La colonna Won't è più utile di quanto sembri. Mettere per iscritto ciò che avete deciso di non fare impedisce che rientri di soppiatto nello sprint e comunica chiaramente agli stakeholder cosa non verrà consegnato.
Formato Must Should Could Won't
Must
Cosa dobbiamo consegnare a ogni costo?
Sono requisiti non negoziabili, fondamentali per il successo. Quando discutete gli elementi 'Must', invitate i partecipanti a pensare ai veri bloccanti o agli elementi essenziali senza i quali il progetto fallirebbe. Spronate il team a essere rigoroso su cosa merita davvero la qualifica di 'Must', per evitare l'inflazione delle priorità.
Should
Cosa è importante ma non critico?
Sono funzionalità o requisiti importanti che aggiungono molto valore ma non sono indispensabili per il lancio. Guidate il team verso gli elementi che sarebbe doloroso escludere ma che non impedirebbero al progetto di funzionare. Concentratevi su elementi di alto valore e urgenza minore.
Could
Cosa sarebbe bello fare se c'è tempo?
Sono funzionalità desiderabili, da realizzare se le risorse lo permettono. Aiutate il team a individuare miglioramenti che renderebbero la soluzione migliore ma non sono essenziali. Spesso sono ottimi candidati per iterazioni o rilasci futuri.
Won't
Cosa decidiamo di non fare questa volta?
Sono gli elementi che il team decide esplicitamente di escludere per questa iterazione o questo progetto. Incoraggiate una discussione sincera sulle funzionalità che potrebbero valere la pena ma non rientrano negli obiettivi o nei vincoli attuali. Dare loro un nome mantiene il team concentrato e chiarisce le aspettative.
Quando utilizzare questa analisi retrospettiva
- Quando pianificate un nuovo progetto o una nuova iniziativa e vi servono priorità chiare
- Durante il backlog refinement, per ordinare e prioritizzare le richieste di funzionalità
- Quando le risorse sono limitate e dovete fare scelte difficili sullo scope
- Nelle riunioni con gli stakeholder, per chiarire cosa verrà consegnato e quando
Domande suggerite per rompere il ghiaccio
- Qual è la decisione di priorità più difficile che hai dovuto prendere in un progetto?
- Se nel tuo progetto attuale potessi consegnare solo tre funzionalità, quali sceglieresti e perché?
Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →
Idee e consigli per la vostra riunione di retrospettiva
- Tenete gli elementi Must entro circa il 60% dell'impegno totale, come suggerisce il DSDM, così il piano ha margine per gli imprevisti
- Rivedete le categorie man mano che cambiano le esigenze di business e i vincoli
- Fissate un timebox per la discussione di ogni elemento, così un solo dibattito non si mangia la riunione
- Annotate perché ogni elemento è finito in una certa categoria, così la prossima discussione non riparte da zero
- Coinvolgete gli stakeholder responsabili dei requisiti, così le priorità reggono nel tempo
- Verificate le dipendenze prima di collocare un elemento: un Could da cui dipende un Must è in realtà un Must
Domande frequenti
Che cos'è il metodo MoSCoW?
Cosa significano Must, Should, Could e Won't?
Come si conduce una retrospettiva MoSCoW?
Perché si chiama MoSCoW?
Quanti elementi dovrebbero essere Must?
Modelli correlati
Trasforma i tuoi obiettivi in traguardi e milestone
Retrospettiva di collaborazione tra team
Elimina gli attriti tra team che dipendono l'uno dall'altro
Analisi SWOT per team
Un template di analisi SWOT per team. Mappate insieme Punti di forza, Punti di debolezza, Opportunità e Minacce, votate ciò che conta e uscite con azioni concrete.
Retrospettiva Sailboat
Individua cosa spinge avanti il team e cosa lo frena