Voir la source de MoSCoW (technique externe et qualitative)

[[Category: Portail Product Owner]]
[[Category: Portail Planification]]
[[Category: Daniel Zacarias]]
[[Category: MoSCoW]]
Auteur : Daniel Zacarias<br />
Source : [https://foldingburritos.com/product-prioritization-techniques/ 20 Product Priorization Techniques: A Map and Guided Tour]<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 12/08/2018<br />
----
Traduction :<br />
<br />
'''Article de référence :''' [[Tableau_périodique_des_techniques_de_priorisation_produit|Tableau périodique des techniques de priorisation produit]]<br/>
<br/>
La [https://en.wikipedia.org/wiki/MoSCoW_method méthode MoSCoW] est une technique de priorisation utilisée dans de multiples domaines de management pour parvenir à un consensus sur les éléments les plus importants pour les parties prenantes et les clients.<br />
<br />
Le terme est un acronyme, chaque lettre représentant l'une des catégories de priorisation possibles (avec des ''O'' ajoutés pour le rendre mémorable). Les exigences sont donc classées comme suit :<br/>
* '''Must''' have  (NdT : Vital) - ces exigences sont critiques et doivent être incluses dans le produit. Même si une seul manque, la version est considérée comme un échec. Ces exigences peuvent être dégradées si les parties prenantes sont d'accord.
* '''Should''' have  (NdT : Essentiel) - ces exigences sont importantes mais pas cruciales pour la version. Elles sont le premier niveau de "Nice to have" (NdT : souhaitable), et partagent généralement l'importance des exigences ''MUST'', sans être aussi sensibles aux échéances.
* '''Could''' have  (NdT : Confort) - ces exigences sont souhaitables mais pas nécessaires pour la version. Elles apportent généralement des améliorations peu coûteuses au produit. En raison de leur faible importance, elles constituent le deuxième niveau de caractéristiques "Nice to have" (NdT : souhaitable).
* '''Won't''' have  (NdT : Luxe) - celles-ci sont considérées comme les moins critiques voire même non alignées avec la stratégie du produit. Elles doivent être définitivement abandonnées ou reconsidérées pour les versions futures.
<br/>
Cette méthode offre une solution de priorisation simple et rapide. Le problème vient de son manque de classement dans les catégories. Par exemple, comment pouvons-nous savoir quelles exigences ''SHOULD'' ou ''COULD'' sont plus importantes que les autres ? En raison de cette limitation, la méthode MoSCoW est probablement mieux adaptée aux projets internes plutôt qu'aux produits avec de nombreux clients. Parler à une poignée de parties prenantes des subtilités de la priorisation sera toujours plus facile que contacter à une plus grande échelle les clients finaux.