fbpx

Cet article est un extrait du Product Academy 1 sur l’Agile Product Management. A travers ce livre, découvrez nos méthodes, nos tools et nos convictions pour vous aider à créer les bons produits !

Loterie

Une fois les user stories plus ou moins détaillées dans le backlog, il s’agit ensuite de les prioriser dans les sprints.

Le Product Owner doit alors se demander par quoi commencer et pourquoi
une user story est plus prioritaire qu’une autre.

L’objectif du Product Owner est de délivrer en priorité ce qu’il juge avoir le plus de valeur pour ses utilisateurs et/ou son entreprise. À l’échelle d’une user story, nous retrouvons ce principe de valeur dans la section « bénéfice attendu ». Néanmoins cette notion est souvent trop vague ou tellement évidente qu’elle ne permet pas une priorisation efficace.

Pour être pertinent, le Product Owner doit prendre en compte d’autres critères et doit élargir son panel d’outils de priorisation. Nous vous proposons dans cette règle de balayer trois outils de priorisation : MoSCoW, Kano et le story mapping.

MoSCoW

Le méthode de MoSCoW permet de prioriser les user stories à moyen terme
selon les critères suivants :

M – Must have : doit être réalisée.
S – Should have : devrait être réalisée si possible.
C – 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 version ultérieure.

Une priorisation par la technique de MoSCoW peut être un bon point de départ, mais c’est une approche qui a certaines limites. Les participants à l’atelier risquent de tomber dans le piège du « tout est important », en raison de leurs expériences des expressions de besoins classiques et du risque – réel ou perçu – que les stories qualifiées comme “Could have” ou “Won’t have” ne soient jamais réalisées. Avec cette façon de penser, une bonne réalisation d’un MoSCoW demande un changement d’état d’esprit important et difficile à obtenir. Il est de la responsabilité du Product Owner d’animer ces ateliers en véhiculant le bon message.

Kano

Cette méthode, créée en 1984 par Noriaki Kano part du constat de l’asymétrie des sentiments de satisfaction et d’insatisfaction qu’un utilisateur peut avoir face à un produit. Un utilisateur peut être moyennement satisfait de la présence d’une fonctionnalité alors que son absence peut être un motif de grande insatisfaction.

Si votre backlog est très fourni, le modèle de Kano permet une priorisation au niveau des grandes fonctionnalités de votre produit. Un atelier de priorisation avec la méthode de Kano se déroule en quatre étapes :

Étape 1 : identification des fonctionnalités.
Étape 2 : consultation des parties prenantes qui doivent répondre aux questions suivantes :

  • Le produit possède cette fonctionnalité, qu’en pensez-vous ? (forme fonctionnelle)
  • Le produit ne possède pas cette fonctionnalité, qu’en pensez-vous ? (forme dysfonctionnelle)

Avec comme 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)
kano

Étape 3 : analyse des résultats (comparaison entre la forme fonctionnelle et dysfonctionnelle) et identification du type de fonctionnalité :

  • Fonctionnalités obligatoires ou essentielles (O) : ce sont les bases de votre produit, les fonctionnalités incontournables.
  • Fonctionnalités linéaires (L) : l’addition de ces fonctionnalités permet d’augmenter la valeur de votre produit.
  • Fonctionnalités excitantes (E) : le « petit plus » de votre produit par rapport à un autre.

Étape finale : visualisation sous forme de diagramme.

Modèle de kano

Cette approche est intéressante car elle se fonde sur une perception du client et elle permet de mettre en évidence des attentes parfois non exprimées.

Story mapping

Le story mapping a été largement abordé dans la règle 4 de ce livre. Il s’agit
d’un excellent outil de priorisation par cohérence fonctionnelle. Une story map est une véritable cartographie du produit qui peut prendre des formes très variées, mais elle permet dans sa forme classique de prioriser entre elles des fonctionnalités de haut niveau.

Cet exercice aboutit à une représentation différente de celle du backlog
puisqu’elle met en avant à la fois des workflows de user stories et des dépendances entre des user stories à forte valeur ajoutée et d’autres non prioritaires ou même techniques.

En outre, cette représentation à d’autant plus de valeur qu’elle est le résultat de discussions et de débats entre les parties prenantes pour aboutir à une vision unique et partagée.

En résumé, les clés d’une bonne priorisation sont de prendre en compte différents critères (et non il n’y a pas que la valeur qui compte !) et d’utiliser le management visuel afin de définir collectivement les priorités.

Ces articles pourraient vous intéresser

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

La Newsletter des Product Managers

Recevez nos articles 2 fois par mois et devenez un top gun du Product Management!