Metodo MoSCoW per assegnare le priorità

Il metodo MoSCoW è stato inventato da Dai Clegg della società di consulenza Oracle UK, che ha sviluppato una tecnica per attribuire le priorità dei progetti che hanno gravi vincoli di tempo ed in cui è necessario individuare le componenti da privilegiare.

Si tratta di uno strumento particolarmente importante da utilizzare nell’Agile Project Management per assegnare le priorità alle diverse funzionalità da sviluppare in modo da costruire un quadro di riferimento chiaro per i vari rilasci di prodotto.

Quando si chiede ad un team di definire insieme ciò che è prioritario emergono visioni diverse e diventa difficile essere sempre imparziali nel giudicare le valutazioni altrui.

Il metodo MoSCoW si applica a user stories e funzionalità e aiuta a rimanere il più possibile razionali ed oggettivi nell’attribuzione di priorità.

I project manager possono utilizzarlo come un approccio ordinato alla definizione delle priorità anche per resistere alle pressioni non sempre giustificate da parte dei diversi stakeholder.

Inoltre, consente a coloro che lavorano direttamente sul progetto di avere una chiara comprensione del perché stanno lavorando su determinate funzionalità o iniziative piuttosto che su altre presenti nel product backlog.

Obiettivo del metodo è sviluppare velocemente prodotti che offrano il più alto valore commerciale possibile individuando quelle componenti a più alto valore aggiunto che è opportuno sviluppare subito.

Le 4 categorie del metodo MoSCoW per assegnare le priorità

Questo approccio prevede quattro categorie in cui ripartire le componenti da sviluppare

• Must have. Si tratta di funzionalità assolutamente fondamentali per il progetto. Senza di loro, è inutile sviluppare il prodotto. Domande chiave:
  • Cosa succede se rilasciamo il prodotto senza questa componente?
  • C’è un modo più semplice per realizzarla?
  • Il prodotto da realizzare funzionerà senza questa funzione?
• Should have. Si tratta anche in questo caso di componenti fondamentali, ma potrebbero non essere così urgenti come le precedenti. Punti di domanda?
  • Quanto valore aggiunge questa funzione al progetto?
  • Può attendere fino alla prossima versione?
• Could have. Queste funzionalità sarebbero belle da avere e migliorerebbero il risultato, ma non sono fondamentali. Se c’è tempo, si può prendere in considerazione la possibilità di integrarle. Nel metodo MoSCoW molte componenti finiranno in questa categoria generando conflitti. E’ quindi importante mantenere la calma puntando su criteri razionali e ponendo le seguenti domande:
  • E’ necessaria questa funzionalità per lo scopo principale del progetto?
  • Quale sarà l’impatto sul progetto se verrà deciso di lasciarla fuori?
  • E’ possibile svolgere rapidamente un’analisi costi/benefici per questa funzionalità?
• Won’t have. Queste caratteristiche non valgono davvero l’investimento di tempo, energia o budget di cui necessitano. Potrebbero, eventualmente, essere considerate in un momento successivo. Punti di verifica:
  • Ciò ha zero o poca importanza per il progetto in questo momento?
  • C’è una possibilità che questo tipo di funzionalità diventino prioritarie in futuro?

Il nome del metodo deriva dalle quattro iniziali delle suddette categorie cui sono state aggiunte delle O per renderlo facilmente pronunciabile e assonante con il nome inglese di Mosca (la capitale della Russia).

Come si fa un’analisi MoSCoW?

I passaggi da seguire sono i seguenti:

• Individuare e raggruppare gli stakeholder. Oltre al team verranno individuati alcuni stakeholder chiave
• Concordare i criteri di valutazione. Verrà deciso se le priorità dovranno essere assegnate tramite votazioni, a maggioranza oppure all’unanimità.
• Condividere il backlog. A questo punto verrà condiviso con tutti gli stakeholder il backlog contenente tutte le funzionalità che dovranno essere valutate secondo le modalità precedentemente illustrate e i criteri concordati.
• Procedere con l’assegnazione delle priorità. Se sorgono disaccordi per una funzionalità, si può passare alle altre componenti del prodotto per poi, alla fine, ritornare sulla valutazione della funzionalità problematica. Al limite, si possono rivedere i criteri e decidere a maggioranza.