Le diagramme de Kano
Le diagramme de Kano a été créé par Noriaki Kano en 1984. C’est une approche intéressante de séparer la satisfaction et la non satisfaction au regard de la présence ou non de la fonction attendue par le client.
Et en Agile ?
Le diagramme de Kano est utilisé par les Product Owner pour les aider à prioriser un ensemble de user-stories. Dans certains projets de grande ampleur, il n’est vraiment pas évident de bien prioriser ses user-stories.
[MISE A JOUR 2019] Je ne vois quasiment plus jamais l’utilisation de cette pratique dans la priorisation de backlog. Cependant il est intéressant de la connaitre.
Mettons en place le diagramme de Kano
Si certaines de vos fonctionnalités sont écrites en plusieurs user-stories, rassemblez les par « Epic » pour vous aider dans votre organisation. Le diagramme de Kano pourra s’appliquer principalement sur les fonctionnalités. Ne pas faire ce travail en amont (ou une pratique aidant à la priorisation par la valeur) vous coûtera du temps et sera un risque d’erreur.
Après ce premier travail, on sépare chaque fonctionnalité (Epic/User-stories) en 3 groupes distincts
- Les fonctionnalités Seuils ou Essentielles
- Fonctionnalités Linéaires
- Les fonctionnalités Excitantes
Les fonctionnalités Seuils ou Essentielles
Ce premier groupement de user-stories et d’Epic est en fait votre MVP (Minimum Viable Product). On met ici toutes les fonctionnalités qui doivent être présentes pour que le produit réussisse.
Article : Qu’est-ce le MVP (Minimum Viable Product) ?
Vous pouvez également comparer ses fonctionnalités comme les MMF (Minimum Marketable Feature) si vous avez l’intension ferme de sortir un produit où une exigence marketing est imposée.
Article : Travaillons nos fonctionnalités avec le MMF
Sur un site ecommerce, il est indispensable de pouvoir payer pour que le client puisse recevoir sa marchandise. On mettra donc cette fonctionnalité comme une fonctionnalité essentielle.
Les fonctionnalités Linéaires
Ce groupe de fonctionnalités va regrouper les fonctionnalités qui ajoutent un vrai plus au produit; sans elles, le produit pourra voir le jour mais il ne sera pas aussi bon aux yeux des utilisateurs.
En gardant comme exemple notre site ecommerce, on pourra par exemple ajouter une option « envoie en 1 jour » au lieu des 3 jours en tant normal. Cela ne sera pas indispensable pour envoyer la marchandise au client mais aujourd’hui les clients seront plus nombreux et satisfaits si il y a des livraisons plus rapide.
Les fonctionnalités Excitantes
Ce groupe de fonctionnalités va permettre de rassembler toutes les fonctionnalités qui n’auront pas d’impact si elles sont absentes ; cependant les utilisateurs adoreront ces fonctionnalités. Si la fonctionnalité n’existe pas, le client n’aurait pas pensé à l’avoir.
Par exemple dans mon site ecommerce, je vais proposer une option dans le panier qui permet d’ajouter une belle carte de vœux et un bel emballage cadeau dans le colis. Si cette fonctionnalité n’est pas présente, cela ne diminuera pas le nombre d’acheteurs.
Diagramme de Kano
Voici à quoi ressemble le diagramme de Kano qui représente l’idée générale que nous avons utilisé pour le classement de nos user-story.
Si il a la place pour le faire, le Product Owner pourra afficher cet énorme diagramme sur un mur (ou le dessiner sur un board) et placer les différentes user-stories (ou Epics) sur celui-ci. Cela peut permettre de mieux prioriser les user-stories au sein même de chaque groupe.
Atelier possible à plusieurs PO
Sur les très gros projets, on réalisera un atelier pour remplir le diagramme de Kano avec le Product Owner voire les parties prenantes concernés par le projet. Chaque participant pourra avoir des post’it de couleurs différentes pour rendre l’ensemble plus lisible.
Cette méthode à plusieurs peut parfois permettre de bien confronter les différents ressentis sur les différentes fonctionnalités.
En général c’est un Scrum Master ou un Coach Agile qui anime cet atelier pour qu’il soit structuré et productif.
Conclusion diagramme de Kano
Le diagramme de Kano est de moins en moins utilisé dans l’agilité. Je vous présenterais d’autres méthodes de priorisation qui sont plus utilisées aujourd’hui.
Comment priorisez-vous vos user-stories de votre côté ? Utilisez-vous le diagramme de Kano ?
Lien utile : definition of value avec le framing agile
2 Rétroliens / Pings