La tecnica MoSCoW: come gestire le priorità ed evitare tutti Must in DSDM e Agile Project Management

La tecnica MoSCoW permette di assegnare le priorità su requisiti o criteri di accettazione. In DSDM® e Agile Project Management® l’utilizzo della tecnica MoSCoW e il corretto bilanciamento dei Must have con gli Should have e  i Could have è fondamentale per avere la contingenza necessaria per e garantire il “Deliver on time“.

Come nella striscia di Dilbert  potrebbero essere presenti una grande quantità di requisiti Must Have o solamente requisiti con questa priorità. Pertanto sarebbe impossibile bilanciarli con la regola del pollice della tecnica MoSCoW relativa all’impegno necessario: 60% Must have, 20% Should have e  20% Could have. Per gestire queste eventualità i manuali del DSDM Consortium descrivono una serie di utili consigli.

Come creare la lista dei requisiti con la tecnica MoSCoW

Inizialmente si consiglia di lavorare a stretto contatto con il Business Visionary (il ruolo che in DSDM® che interpreta le necessità del business e le comunica al Team) per fargli comprendere come devono essere assegnate le priorità. Quindi  spiegare al Team di lavorare considerando le priorità e non solo su cosa è più divertente.

Una buona strategia è partire inserendo tutti i requisiti come Won’t Haves. Per ogni requisito stimare e fare previsioni sull’impegno necessario per soddisfare i requisiti (in Agile sono presenti molte tecniche interessanti come il Planning Poker o l’utilizzo dei Gummi Bear).Procedere quindi cercando delle giustificazioni per far crescere la priorità di ogni requisito. Reiterare più volte sulla lista, facendo particolare attenzione ai Must Have e al rispettivo bilanciamento secondo la regola del 60-20-20.

Domande da utilizzare per dare le priorità

Per ogni requisito identificato come Must Have, domandare:

• “Cosa succede se il requisito non viene soddisfatto?”. Se la risposta è “Cancellare il progetto, non ci sono altri modi per implementare la soluzione senza soddisfare questo requisito” allora è un Must Have.
• “Arrivo da te la notte prima del rilascio e ti dico che c’è un problema con questo requisito e non possiamo rilasciare. Fermiamo il progetto?”. Se la risposta è “Si” allora è un Must Have.
• “E’ possibile utilizzare un work-around, anche manuale per soddisfare il requisito?”. Se la risposta è “Si” allora non è un Must Have.
• “Il Business Case – se di sufficiente dettaglio – può essere usato per giustificare la priorità del requisito?”. Se la risposta è “Si” allora probabilmente è un Must Have.
• “Il requisito è un Must Have e dipende da altri? Quelli da cui dipende sono tutti Must Have?“. Se la risposta è “No” allora valutare le dipendenze, un Must Have deve dipendere solo da altri Must Have.
• “Il requisito Must Have fa riferimento ad un obiettivo del progetto che è anche questo un Must Have?”. Se la risposta è “No”, considerare come Must Have solo i requisiti che fanno riferimento agli obiettivi principali.
• “Il requisito è necessario per l’aderenza a leggi o regolamentazioni?”. Se la risposta è “Si”, allora è un Must Have.
• “Se ci sono problemi con il requisito, abbiamo problemi di sicurezza?”.  Se la risposta è “Si”, allora è un Must Have.

Per capire invece la differenza tra uno Should Have e un Could Have, domandare:

• “Quanto è doloroso non soddisfare il requisito?”. Se è molto doloroso, ma la soluzione è comunque fattibile, allora è uno Should Have. Se invece non è doloroso escludere un requisito allora è un Could Have

Più in generale per scomporre requisiti o capire se hanno differenti livelli – sia per i Must Have che per quelli di altra priorità – domandare:

• “Il requisito può essere scomposto? I requisiti ottenuti hanno diverse priorità?” Se la risposta è “Si” allora scomporre il requisito e assegnare diverse priorità.
• “E’ possibile utilizzare differenti livelli di accettazione di un requisito?” Per esempio. Deve essere possibile ripristinare il backup al più presto possibile. “Quanto presto?”. La risposta potrebbe essere: “Should in 4 ore, ma Must in 24 ore”.

A cosa si può dare priorità con tecnica MoSCoW?

DSDM Atern consiglia di utilizzare la tecnica MoSCoW anche per:

• Gestire bug e difetti
• Le attività di testing
• liste di attività e cose da fare

Risorse e riferimenti

• Il nostro post sulla Tecnica MoSCoW – come assegnare le priorità
• Il nostro post sulla Tecnica MoSCoW – come bilanciare le priorità
• Il manuale “Atern® Handbook” edito dal DSDM® Consortium
• Il manuale “Agile Project Management Handbook” edito dal DSDM® Consortium

Secondo te…

• Ci sono altri consigli che possono essere utilizzati?
• Altre domande per comprendere al meglio i Must have?
• Domande utili per capire se un requisito è uno Should o un Could?

Copyright

PRINCE2®, ITIL®, M_o_R® sono marchi registrati della AXELOS Limited.
DSDM®, Atern® e Agile Project Management™ 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.