#6. Priorisez votre Backlog

Trois méthodes pour prioriser convenablement la longue liste de User Stories que vous avez à gérer.

Thiga - Product Management. Redefined.
Thiga
5 min readAug 16, 2016

--

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’é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.

L’objectif du Product Owner est de livrer en priorité ce qu’il juge avoir le plus de valeur pour ses utilisateurs et/ou son entreprise.

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 :
MoMust have : doit être réalisée.
SShould have : devrait être réalisée si possible.
CoCould have : pourrait être réalisée s’il n’y a pas d’impact sur les autres tâches en cours.
WWon’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.

Le modèle de Kano permet une priorisation focalisée sur les sentiments de vos clients à propos 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 (idéalement des clients) 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)

É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.
Matrice KANO permettant de classer les fonctionnalités au regard des retours des parties prenantes

O > Obligatoire/Essentielle
L > Linéaire
E > Excitante
C > Contradictoire
Q > Questionnable
I > Indifférent

Étape finale : visualisation sous forme de diagramme.

Modélisation des types de fonctionnalités classées selon le 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.

Pour en savoir plus sur la méthode Kano, vous pouvez consulter le brillant article de Daniel Zacarias sur son blog

Story mapping

Le story mapping a été largement abordé dans la règle 4 du Product Academy. 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.

Cet article a originalement été publié dans notre Product Academy. Si vous voulez un compagnon physique demandez votre exemplaire sur notre site !

Et si vous avez aimé cet article, n’hésitez pas à nous donner un petit coeur !

--

--

Thiga - Product Management. Redefined.
Thiga
Editor for

#ProductManagement #DesignThinking #ProductDesign #LeanStartup #LeanUX