La tecnica MoSCoW: come assegnare le priorità su DSDM, Agile PM, PRINCE2, ITIL e BABOK

4 Comments / By /

La tecnica MoSCoW è una delle migliori tecniche per l’assegnazione delle priorità che può essere applicata a una lista di requisiti (funzionali e non funzionali), attività, use case, user story, criteri di accettazione e test di valutazione. E’ utile per gestire le attività di consulenza, di sviluppo software o di progetto, come per gestire il day-by-day della vita privata.

1697.strip
Come nella striscia di Dilbert, siamo abituati a lavorare – nella gestione dei progetti, come nello sviluppo software – con requisiti totalmente urgenti e importanti. Ma un sondaggio eseguito durante l’ottimo webinar di Keith Richards “Master the art of MoSCoW prioritisation to protect the quality of what you deliver and deliver it on time” dimostra che una certa percentuale di requisiti – anche se classificati come necessari e rilasciati – non viene poi utilizzata se non raramente. Pertanto è utile concentrarsi solo su quei requisiti veramente importanti. Per gestire questi elementi è possibile usare la tecnica MoSCoW.

Come funziona la tecnica MoSCoW?

Il primo passo è classificare gli elementi della lista in base a 4  livelli di priorità:

  • Must have: Descrive un elemento di vitale importanza. Se questo viene disatteso il progetto, il prodotto, l’attività o la soluzione non può essere completato.
  • Should have: Descrive un elemento importante e in alta priorità e che dovrebbe essere soddisfatto.
  • Could have: Descrive un elemento desiderabile, ma non strettamente necessario.
  • Won’t have this time, but would like: Descrive un elemento che non sarà soddisfatto in questo momento.

Una trasposizione italiana  –  non ufficiale – dell’acronimo MoSCoW è  VIDE (Vitale, Importante, Desiderabile, Evitabile per ora).

La tecnica MoSCoW descrive poi le regole di esclusione nel caso si verifichino dei problemi: ci dice come eseguire il de-scope  di  alcuni elementi della  lista (‘riduzione’ dello scope). I primi ad essere rimossi sono gli elementi classificati Could, seguiti dagli Should, che all’atto pratico vengono inseriti tra i Won’t. I Must non possono essere rimossi e solitamente l’obiettivo è di soddisfare almeno anche gli Should.

Come consigliato in Atern i Must non devono essere la totalità dei requisiti. Come Rule of Thumb, i Must dovrebbero comprendere  non più del 60% di effort rispetto al totale. Inoltre se sono presenti solo Must allora questi devono essere “esplosi” in requisiti più piccoli – che comprenderanno sia alcuni Must che altri Could e Should, se non dei Won’t.

Esempio di utilizzo della tecnica MoSCoW

Per organizzare una vacanza è possibile definire delle priorità per l’organizzazione del viaggio. Per l’hotel la posizione, tipologia o i servizi che offre; per il mezzo di trasporto quale usare (treno, aero, automobile, nave), eventualmente di una compagnia specifica o con determinati confort. Per alcuni sono Must le caratteristiche dell’hotel, per altri un viaggio comodo… dipende dalle priorità di ognuno.

Dove possiamo utilizzare MoSCoW?

La tecnica MoSCoW è stata sviluppata da Dai Clegg di Oracle UK Consulting per il RAD (Rapid Application Development). Poi donata al DSDM® Consortium (Dynamic Systems Development Method) che ben la descrive nel proprio framework Agile e in Agile Project Management® – creato in collaborazione con APM Group focalizzandosi sugli aspetti di Project Management  di Atern®. E’ una delle 5 tecniche chiave di DSDM®. Può essere facilmente utilizzata o integrata con:

  • DSDM®, per definire le priorità nella Prioritized Requirement List (PRL).
  • PRINCE2®, per definire le priorità dei Criteri di Accettazione delle Tolleranze o assegnare le priorità alle Questioni.
  • ITIL®, per dare priorità ai requisiti di un servizio, come in fase di Design.
  • BABOK®, per prioritizzare gli Acceptance e gli Evaluation Criteria.

MoSCoW e Scrum?

Scrum necessita di un paragrafo a parte. Nella revisione di Giugno 2011 della Scrum Guide è stata infatti modificata la definizione di Product Backlog (PB) da “lista in priorità” a “lista ordinata”. Pertanto l’utilizzo della tecnica MoSCoW – che serve per assegnare le priorità – non è consigliata. Inoltre il termine “Must” implica la  “garanzia” di rilascio e quindi “commitment”, altro termine aggiornato nella stessa revisione con “forecast”. Non a caso, durante lo durante lo Sprint Planning Meeting, il Product Owner (PO) propone – e non impone – al Team gli item da inserire nello Sprint Backlog. Quindi per un ordinamento è più idoneo l’utilizzo di semplici numeri.

Risorse e Riferimenti

Copyright

PRINCE2®, ITIL®, M_o_R® sono marchi registrati della AXELOS Limited.
DSDM® e Atern® sono marchi registrati da Dynamic Systems Development Method Limited
BABOK®, Business Analysis Body of Knowledge®, IIBA® e International Institute of Business Analysis® e sono marchi registrati registrati dall’International Institute of Business Analysis®
ISACA® è un marchio registrato dell’Information Systems Audit and Control Association
COBIT® è un marchio registrato dell’Information Systems Audit and Control Association e dell’IT. Governance Institute.
ScrumAlliance® è un marchio registrato dalla Scrum Alliance.

Scroll to Top