3 méthodes pour prioriser ses user stories.

3 méthodes pour prioriser ses user stories.

 

Une fois les user stories détaillées, il convient de les prioriser.L’objectif du Product Owner sera de livrer en priorité ce qui est jugé avoir le plus de valeur (précisé dans lasection Bénéfice attendu de ses user stories) pour ses utilisateurs et/ou son entreprise. Lorsque cettenotion demeure insuffisante pour hiérarchiser ses priorités, trois méthodes permettent d’élargir lescritères de sélection et peuvent être réalisées en ateliers d’intelligence collective:1/ La méthode de MoSCoWElle permet de prioriser les user stories à moyen terme selon les critères suivants :Mo — Must have : doit être réalisée.S — Should have : devrait être réalisée si possible.Co — Could have : pourrait être réalisée s’il n’y a pas d’impact sur les autres tâches en cours.W — Won’t have : ne sera pas réalisée tout de suite mais serait souhaitable pour une versionultérieure.2) Le modèle d’alignement d’objectifs de Niel NickolaisenPlus poussé que la méthode de MoSCoW qui présente la limite de générer de nombreux « Musthave », les parties prenantes ayant tendance à considérer toutes les fonctionnalités commeprioritaires, ce modèle amène à se poser deux questions pour chaque élément à prioriser:1- Est-ce une mission critique (l’entreprise peut-elle fonctionner sans) ?2- Est-ce différenciant sur le marché (cela apporte-t-il un avantage concurrentiel) ? A la fois critique etdifférenciant.L’organisation doit yconcentrer l’essentielde ses investissements.Peut être fait mais n’ayantpas besoin d’êtrenettement meilleur quechez la concurrenceDifférenciant mais nefaisant pas partie desmission critique del’entreprise3/ Le modèle de KanoCette méthode, créée en 1984 par Noriaki Kano part du constat selon lequel un utilisateur peut êtremoyennement demandeur de la présence d’une fonctionnalité alors que son absence peut être unmotif de grande insatisfaction.Pour prioriser les fonctionnalités selon ce modèle, il convient de répondre, pour chacune desfonctionnalités imaginées, là aussi, à deux questions. L’idéal étant de poser ces questions au client ouà l’utilisateur final de la solution :1- Le produit possède cette fonctionnalité, qu’en pensez-vous ? (forme fonctionnelle)2- Le produit ne possède pas cette fonctionnalité, qu’en pensez-vous ? (forme dysfonctionnelle)Avec pour chaque question, 5 réponses possibles : « Aime » (J’aimerais ça) « Attend » (Je m’attends à ce qu’il en soit ainsi) « Neutre » (Cela m’est égal) « Vit avec » (Je l’accepte) « N’aime pas » (Je n’aimerais pas ça)L’analyse des réponses se fait alors grâce à la matrice suivante :Ni essentiel, nidifférenciant.O > Obligatoire/EssentielleL > LinéaireE > ExcitanteC > ContradictoireQ > QuestionnableI > Indifférent