Définition de priorités

Par Mitch Lacey. Propriétaire : Mitch Lacey & Associates, Inc, cabinet de consultants spécialisé dans l'adoption et l'amélioration des pratiques Agile et Scrum.

Janvier 2012

Dans cet article, Mitch Lacey présente trois méthodes qui se sont prouvées très salutaires pour de nombreuses équipes Agile : le modèle Kano de satisfaction client, une série d'Innovation Games de Luke Hohmann, et le modèle Relative Weighting de Karl Weigers. Toutes ces méthodes peuvent vous aider à passer de la définition approximative des priorités de votre backlog à une hiérarchisation précise qui mesure d'une manière satisfaisante le risque, l'importance et la satisfaction client.

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server

Dans cet article :

• Introduction

• Le modèle de satisfaction client de Kano

• Innovation Games

  • Prune the Product Tree

  • Buy a Feature

• Relative Weighting – Karl Wiegers

• Conclusion

Pour garantir l'efficacité de votre équipe Agile, vous devez classer par priorité les éléments de votre Backlog de produit, puis mettre à jour ces priorités à mesure que le projet avance. La définition des priorités au sein des backlogs de produit doit être basée sur la valeur commerciale et le risque. Une fois l'ordre de priorité accepté, votre équipe peut mieux se concentrer sur les fonctionnalités qui sont plus susceptibles de contribuer à la réussite de votre produit. Un backlog bien hiérarchisé a des effets bénéfiques non seulement pour l'équipe et la satisfaction client, mais également pour les affaires. Pour plus d'informations sur les backlogs, consultez Générer et gérer le backlog de produit, Créer votre backlog et Nettoyer et estimer le journal des travaux en souffrance (backlog).

Lorsque vous définissez les priorités au sein du backlog de produit, vous devez tenir compte de nombreux facteurs et pouvoir justifier vos décisions. Lorsque vous vous attaquez à un backlog de produit non encore traité, le processus peut sembler presque insurmontable. Heureusement, il n'est pas nécessaire de hiérarchiser chaque élément du backlog de façon définitive dès le début. Dans Estimation, je décris une technique appelée "The Big Wall" (ou Grand mur) qui permet d'évaluer rapidement et efficacement un backlog de produit brut et d'aboutir à une première définition des priorités avec les différentes parties prenantes.

Cette première définition des priorités est un bon point de départ et peut être suffisante dans certains cas. Dans certains cas, toutefois, vous pourriez avoir besoin d'affiner ces priorités ou d'aboutir à une hiérarchisation d'une manière plus scientifique. Il existe pour cela de nombreuses techniques. Dans l'article qui suit, je présenterai trois méthodes qui se sont révélées très salutaires pour de nombreuses équipes Agile : le modèle de satisfaction client de Kano, les jeux Innovation Games de Luke Hohmann et le modèle Relative Weighting de Karl Wiegers. Toutes ces méthodes peuvent vous aider à passer de la définition approximative des priorités de votre backlog à une hiérarchisation précise qui mesure d'une manière satisfaisante le risque, l'importance et la satisfaction client.

Le modèle de satisfaction client de Kano

Le modèle de satisfaction client de Kano a été développé dans les années 1980 par le Professeur Noriaki Kano de l'Université Rika de Tokyo. Son modèle fournit un système de classement simple qui permet de distinguer les attributs essentiels des attributs de différenciation. Ce modèle basé sur un questionnaire est un outil puissant permettant de visualiser les caractéristiques produit et de favoriser le débat au sein de l'équipe Conception.

Avec le modèle de Kano, nous posons une série de questions de deux types : dysfonctionnelles et fonctionnelles. Imaginons, par exemple, que nous posions à des clients des questions concernant un système GPS pour voiture. Nous poserions d'abord la question sous sa forme fonctionnelle :

• Que penseriez-vous si cette voiture était équipée d'un système GPS ?

De cette façon, nous limitons les possibilités de réponse à ce qui suit :

• Ce serait une bonne chose.

• Cela me paraît normal qu'elle en soit équipée.

• Je n'ai pas d'avis.

• Cela ne me dérangerait pas.

• Je n'aimerais pas qu'elle en soit équipée.

Pour cet exemple, supposons que nos clients fictifs aient répondu "Ce serait une bonne chose".

Ensuite, nous posons la même question sous sa forme dysfonctionnelle :

• Que penseriez-vous si cette voiture n'était pas équipée d'un système GPS ?

Nos clients fictifs pourraient choisir parmi les réponses proposées. La réponse est souvent, et même généralement, différente. Pour cet exemple, supposons que nos clients fictifs aient répondu "Cela me paraît normal qu'elle en soit équipée" à la question dysfonctionnelle.

Dans le cadre d'un projet réel, nous pouvons poser ces différents types de questions à plusieurs groupes de clients, c'est-à-dire, à différents groupes d'individus occupant différents postes au sein de l'organisation cliente. Par exemple, un groupe Marketing, un groupe Comptabilité, un groupe Fabrication, etc. Pour mieux comprendre ce modèle, imaginons que nous posions une seule question à un seul groupe client. Une fois notre paire de réponses obtenue (les réponses à la question fonctionnelle et à la question dysfonctionnelle), nous les copions dans une grille, comme le montre le Tableau 1.

Tableau 1 : Modèle de Kano – Copie des réponses

Notez que, dans notre exemple, les clients fictifs ont répondu aime à la question fonctionnelle et normal à la question dysfonctionnelle. Quand vous copiez la paire de réponses dans la grille, vous voyez qu'un E se trouve à l'intersection des deux attributs (indiquée en jaune). Voyons ce que cela signifie pour notre backlog hiérarchisé.

• E = Excitant. Il s'agit des fonctionnalités que le client n'avait pas prévues et qui différencient véritablement un produit de ses concurrents. Elles sont difficiles à identifier, en particulier au départ, car il peut être difficile de trouver des questions permettant d'obtenir des fonctionnalités intéressantes. Pour cette raison, les éléments excitants ont tendance à devenir prioritaires à mesure que le projet avance et que les commentaires client arrivent.

  • Les clients sont très satisfaits de ces fonctionnalités et sont prêts à payer un supplément pour en disposer. Par exemple, l'iPod d'Apple ravit les clients grâce à sa capacité intuitive de changer l'orientation de l'écran en même temps que celle de l'appareil. L'absence de cette fonctionnalité n'aurait cependant pas diminué leur satisfaction, car ils n'auraient pas pu trouver normale son existence.

  • Dans notre exemple, le système GPS est une fonctionnalité excitante. L'étude de cette fonctionnalité, au moins jusqu'à recevoir des commentaires client, doit être placée relativement haut lors de la hiérarchisation.

• B = Basique. Ces fonctionnalités doivent être comprises dans le produit. Il s'agit des fonctionnalités essentielles situées en haut de la liste des priorités.

  • Même si ces attributs basiques sont très bien exécutés, le client restera neutre à l'égard du produit. Un traitement de texte, par exemple, doit posséder les fonctionnalités de création et d'enregistrement d'un document. Il s'agit là de fonctionnalités indispensables.

  • Si nous avions posé à notre groupe de clients une question sur les ceintures de sécurité, la plupart auraient répondu qu'il leur paraît normal qu'une nouvelle voiture soit équipée de ceintures de sécurité et qu'ils n'aimeraient pas qu'elle n'en soit pas équipée. Si nous copions ces deux réponses dans la grille, nous voyons que les ceintures sont considérées comme un élément basique (B) et indispensable.

• L = Linéaire. Également appelées "exigences de performances", les fonctionnalités linéaires sont directement liées à la satisfaction client. Elles arrivent juste derrière les fonctionnalités basiques en matière de priorité et doivent être mises en balance en fonction de leur coût.

  • L'amélioration de la fonctionnalité ou de la qualité d'exécution accroît la satisfaction client. Une détérioration de la fonctionnalité entraîne une diminution de la satisfaction.

  • Le prix du produit est souvent lié à ces attributs.

• I = Indifférent. Ces fonctionnalités sont moins importantes pour le client et, par conséquent, doivent être considérées comme les moins essentielles au produit. Elles n'apporteraient que peu de valeur commerciale, voire aucune.

Le Tableau 1 contient également les lettres Q et R.

• Q : Douteux (Questionable) – La question est probablement incorrecte ou la réponse est suspecte.

• R : Contradictoire (Reverse) – Les deux réponses sont contradictoires. Prenons le système GPS. Une personne pourrait trouver normal que la voiture en soit équipée, mais préférer qu'elle n'en soit pas équipée. Il s'agit d'une réponse de type R (contradictoire).

Si une paire de réponses est évaluée comme étant du type Q ou R, vous devrez vous pencher sur vos questions ou sur la paire de réponses.

Innovation Games

Les Innovation Games sont des outils permettant d'effectuer des études de marché primaires. Grâce à ces outils, les clients jouent à des "jeux" dans le but d'obtenir des remarques et des suggestions concernant un produit ou un service. Luke Hohmann a créé plus de 12 de ces jeux qu'il décrit dans son livre Innovation Games, que nous vous recommandons vivement. Mes deux jeux favoris pour hiérarchiser un backlog sont Prune the Product Tree et Buy a Feature, que Luke décrit dans cet extrait (utilisé avec son autorisation) :

Prune the Product Tree

Les jardiniers taillent les arbres pour contrôler leur croissance. Parfois, la taille est artistique et nous obtenons des arbustes prenant la forme d'animaux ou de formes abstraites. La plupart du temps, la taille a pour but d'équilibrer l'arbre qui pourra alors donner des fruits de grande qualité. Ce processus ne consiste pas à "couper", mais à "donner une forme". Utilisez cette métaphore pour créer le produit qu'attendent vos clients.

Le jeu

Commencez par dessiner un grand arbre sur un tableau blanc ou sur du papier dessin, ou bien imprimez l'image d'un arbre de la taille d'une affiche grand format. Les branches épaisses représentent les principales catégories de fonctionnalités au sein de votre système. L'extérieur de l'arbre (les branches les plus éloignées) représentent les fonctionnalités disponibles dans la version actuelle. Écrivez des fonctionnalités potentielles sur des fiches cartonnées, prenant, dans l'idéal, la forme de feuilles. Demandez à vos clients de placer les fonctionnalités souhaitées sur l'arbre, afin de définir la prochaine phase de sa croissance. La structure de l'arbre est-elle équilibrée ? La croissance se situe-t-elle majoritairement au niveau d'une même branche, représentant peut-être une fonctionnalité basique ? Une partie sous-utilisée de l'arbre est-elle en train de se renforcer ? Nous savons que les racines d'un arbre (votre structure de support et service client) doivent être au moins aussi étendues que la cime. Est-ce le cas du vôtre ?

L'arbre du produit – Hohmann

Comment cela fonctionne

Vos clients et vous-même savez que toutes les fonctionnalités n'ont pas la même importance. Par conséquent, nous avons tendance à concentrer nos efforts sur les fonctionnalités les plus importantes, celles qui ont la plus grande valeur aux yeux des clients. Malheureusement, cela signifie parfois que nous plaçons trop peu d'efforts dans les fonctionnalités qui sont nécessaires pour rendre le produit unique. Le jeu Prune the Product Tree permet aux clients d'apporter leurs suggestions lors du processus décisionnel grâce à une vue d'ensemble des fonctionnalités qui composent le produit.

Buy a Feature

Quelle fonctionnalité incitera les clients à acheter votre produit ? Quelle fonctionnalité fera passer le client au niveau de qualité supérieur ? Quelle fonctionnalité ravira tant le client qu'il en oubliera les fonctionnalités qui le dérangent ou qu'il souhaiterait améliorer ?

Les chefs de produit ne cessent de se poser ces questions. Le bon choix de fonctionnalités est souvent ce qui permet d'obtenir un succès à long terme. Malheureusement, les chefs de produit font trop souvent ce choix sans impliquer les personnes les plus concernées : les clients. Le jeu Buy a Feature permet de prendre de meilleures décisions en sollicitant l'aide des clients.

Buy a Feature – Sterne

Le jeu

Créez une liste de fonctionnalités potentielles et attribuez un prix à chacune. Comme pour un vrai produit, le prix peut être basé sur les coûts de développement, la valeur client ou autre chose. Même si le prix peut correspondre au coût réel que vous avez l'intention d'attribuer à la fonctionnalité, cela n'est généralement pas obligatoire. Les clients achètent les fonctionnalités qu'ils souhaitent avoir dans la prochaine version de votre produit à l'aide d'argent factice. Faites en sorte que certaines fonctionnalités soient suffisamment chères pour qu'aucun client ne souhaite les acheter. Encouragez les clients à mettre en commun leur argent pour acheter les fonctionnalités les plus importantes et/ou les plus coûteuses. Cela favorisera le débat entre les clients quant aux fonctionnalités les plus importantes.

Ce jeu est plus efficace avec un groupe de quatre à sept personnes. Les clients auront ainsi davantage d'occasions de mettre leur argent en commun après avoir débattu des fonctionnalités les plus importantes. Contrairement au jeu Product Box, le jeu Buy a Feature est basé sur une liste de fonctionnalités susceptibles de faire partie de votre plan de développement.

Comment cela fonctionne

Les chefs de produit pensent souvent à tort que les clients ont eux-mêmes clairement défini des priorités quant au produit. C'est le cas de certains. Mais dans la plupart des cas, ils ne le font pas. Lorsqu'on leur présente un ensemble d'options, la plupart des clients disent "Je les veux toutes", vous donnant ainsi la responsabilité de hiérarchiser leurs demandes. Parfois, les chefs de produit parviennent à une hiérarchisation des fonctionnalités en interrogeant chaque client individuellement, sans se rendre compte qu'en procédant ainsi, ils définissent eux-mêmes la priorité des fonctionnalités. En impliquant un groupe de clients et en leur fournissant un nombre limité de ressources, vous leur donnez l'occasion de hiérarchiser leurs souhaits en tant que groupe. Mais ce n'est pas là que se trouve l'astuce. L'astuce vient du fait que les conversations sont structurées de telle sorte que les clients doivent débattre des fonctionnalités les plus importantes. C'est ce débat qui vous permet de mieux comprendre ce que veulent vraiment vos clients.

Relative Weighting – Karl Wiegers

Une autre excellente méthode de hiérarchisation est celle introduite en 1999 par Karl Wiegers, le Relative Weighting. Non seulement cette méthode fournit un mécanisme de hiérarchisation des besoins basé sur les commentaires des utilisateurs, mais elle fournit également le jugement expert de l'équipe. Tout comme le modèle de Kano et les Innovation Games, Relative Weighting permet au chef de produit de déterminer plus facilement les fonctionnalités à implémenter et dans quel ordre de priorité.

La première étape consiste à attribuer un poids à l'avantage relatif d'une fonctionnalité. Un avantage correspond au bénéfice que pourraient tirer les utilisateurs d'une fonctionnalité si elle était intégrée au produit final. La deuxième étape consiste à attribuer une pénalité relative. La pénalité correspond aux conséquences, pour les utilisateurs, de ne pas disposer d'une fonctionnalité donnée dans le produit final. L'évaluation des avantages et des pénalités revient à utiliser les questions fonctionnelle et dysfonctionnelle du modèle de Kano. Les poids sont des valeurs arbitraires qui représentent la manière dont votre entreprise évalue les avantages et les risques des fonctionnalités. Ceci est très similaire à la façon dont un enseignant détermine le coefficient à attribuer aux devoirs, à l'assiduité et aux résultats d'examens pour obtenir une note générale. Cette évaluation varie selon les enseignants. Si vous décidez que les avantages l'emportent sur les pénalités, attribuez-leur un poids supérieur à celui des pénalités, selon le rapport de votre choix. Si vous décidez que les pénalités l'emportent sur les avantages, ajustez le poids en conséquence. Dans l'exemple du Tableau 2, nous avons donné à l'avantage un poids relatif de 2 et à la pénalité, un poids relatif de 1. Cela signifie que l'avantage sera un facteur plus déterminant dans la définition finale des priorités.

De la même façon, nous déterminons le poids du pourcentage de coût et du pourcentage de risque. Dans l'exemple suivant, le risque n'était pas une grande préoccupation. Nous avons donc attribué au pourcentage de coût un poids de 1 et au pourcentage de risque, un poids de 0,5. Notez toutefois que même si un poids est attribué aux avantages et aux pénalités avant le calcul du pourcentage de valeur, le poids des coûts et des risques est exprimé en pourcentage. Si votre projet comporte des risques élevés, vous pouvez attribuer au risque un poids supérieur à celui du coût.

Maintenant que les poids sont définis, vous demandez aux utilisateurs d'évaluer l'avantage relatif et la pénalité relative de chaque fonctionnalité. Les avantages et les pénalités sont évalués selon une échelle (Wiegers recommande une échelle de 1 à 9), mais vous pouvez choisir une autre échelle, du moment que vous restez cohérent. L'avantage relatif correspond à la valeur qu'apporte une fonctionnalité. La pénalité relative correspond à l'impact négatif potentiel qu'impliquerait l'absence de cette fonctionnalité.

Par exemple, imaginons la fonctionnalité suivante "Rendre le widget conforme aux réglementations Sarbanes-Oxley". Cette fonctionnalité ne présente aucun avantage relatif pour les utilisateurs, mais la pénalité relative pour l'entreprise est grande. Ne pas l'implémenter pourrait entraîner la fermeture de l'entreprise. Par conséquent, nous pourrions avoir un score de 1 ou de 2 pour l'avantage relatif et un score de 8 ou de 9 pour la pénalité relative.

Dans l'exemple suivant, les utilisateurs ont attribué un score de 5 à la fonctionnalité "Interroger le statut d'une commande fournisseur". Ils ont attribué à sa pénalité relative un score de 3. Pour calculer la valeur totale de cette fonctionnalité, nous multiplions ces deux nombres par leurs poids relatif, puis nous les ajoutons :

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

Dans ce cas, la valeur totale de cette fonctionnalité est de 13 points.

Une fois obtenus la valeur relative totale et le pourcentage de valeur des fonctionnalités, nous nous éloignons des utilisateurs pour obtenir l'avis de l'équipe. Nous demandons à l'équipe d'estimer le coût relatif de l'implémentation de chaque fonctionnalité en utilisant la même échelle. Karl Wiegers explique : "Les développeurs estiment les coûts en fonction de facteurs tels que la complexité des exigences, le travail requis pour l'interface utilisateur, la possibilité de réutiliser des conceptions ou du code existants, les niveaux de test et la documentation nécessaire".

Une fois le coût relatif estimé, nous estimons le risque relatif. Là encore, Wiegers explique: "Les développeurs estiment le degré relatif du risque technique, ou autre type de risque, associé à chaque fonctionnalité, sur une échelle de 1 à 9. Une estimation de 1 signifie que vous pouvez la programmer dans votre sommeil, tandis que 9 indique des préoccupations importantes concernant la faisabilité, la disponibilité du personnel ayant les compétences nécessaires ou l'utilisation de technologies et d'outils peu connus. La feuille de calcul calculera le pourcentage du total risque associé à chaque fonctionnalité."

Une fois obtenues les valeurs de l'avantage, de la pénalité, du coût et du risque relatifs, nous pouvons résumer chaque colonne. Ces totaux seront utilisés pour calculer les pourcentages.

• Pourcentage total de la valeur : divisez la somme des valeurs de l'avantage relatif et de la pénalité relative par le total situé au bas du tableau. Dans l'exemple suivant, il s'agit de 13/154 = 8 %.

• Pourcentage du coût relatif : divisez la valeur du coût relatif par le coût relatif total situé au bas du tableau. Dans l'exemple suivant, il s'agit de 2/42 = 4,8 %.

• Pourcentage du risque relatif : divisez la valeur du risque relatif par le risque relatif total situé au bas du tableau. Dans l'exemple suivant, il s'agit de 1/33 = 3 %.

• Priorité : divisez le pourcentage de valeur par (pourcentage de coût * poids du coût) + (pourcentage de risque * poids du risque). Dans l'exemple suivant, il s'agit de 8,4 %/((4,8 % * 1) + (3 % * 0,5). On obtient alors la valeur de priorité (1,345).

Une fois obtenues les valeurs de priorité, nous classons la colonne de priorité dans l'ordre décroissant pour que les éléments avec la priorité la plus élevée se retrouvent en haut. Nous devrons réévaluer les priorités à mesure que nous ajoutons des éléments et des informations au backlog de produit.

Au final, la feuille de calcul ressemblera à ce tableau :

En adoptant cette approche, vous pouvez mieux comprendre ce qui convient à l'équipe et aux parties prenantes. Cela permet également de mieux ancrer les débats, car il peut être difficile d'évaluer objectivement les éléments tels que les avantages, les pénalités, les coûts et les risques de chaque fonctionnalité.

Wiegers explique comment mieux rapprocher le modèle de la réalité :

"Adaptez ce modèle à votre propre utilisation à l'aide d'un ensemble d'exigences ou de fonctionnalités finalisées provenant d'un produit précédent. Ajustez les facteurs de poids jusqu'à ce que l'ordre de priorité calculé corresponde à votre évaluation de l'importance des exigences de votre ensemble de tests. Ce modèle peut également vous aider à adopter des solutions de compromis lorsque vous évaluez de nouvelles propositions d'exigences. Estimez leur priorité à l'aide du modèle pour savoir si elles répondent aux exigences actuelles. Vous pourrez ainsi choisir un ordre de mise en œuvre adapté. Le fait de rendre la hiérarchisation des exigences plus objective et analytique que politique permettra au projet de fournir les fonctionnalités les plus importantes dans l'ordre le plus adapté."

Karl Wiegers a écrit deux livres qui abordent en détail le Relative Weighting : Software Requirements, deuxième édition et More About Software Requirements: Thorny Issues and Practical Advice.

Que vous utilisiez l'une de ces méthodes ou une autre technique, n'oubliez pas que le backlog est un objet évolutif. Pour garantir la qualité d'un backlog, les priorités doivent être régulièrement redéfinies. Pour que votre projet se déroule bien, vous devez réévaluer constamment les récits utilisateurs, leur importance pour le projet et la manière dont les nouvelles informations affectent le backlog. Vous devez obligatoirement impliquer les clients et les parties prenantes tout au long du projet. En outre, vous devez vous rappeler que l'estimation d'un élément est essentielle pour déterminer sa priorité. Ne laissez pas vos backlogs devenir obsolètes. Prenez le temps de soigner votre backlog. Vous en récolterez les fruits non seulement pour le produit final, mais également pour vos affaires.

Voir aussi

Concepts

Collaborer (approfondir) [redirection]

Collaborer [redirection]

Demande et commentaires des parties prenantes de révision à l'aide de team Web access

Suivre le travail et gérer le flux de travail [redirection]

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   "Attractive Quality and Must-be Quality" Noriaki Kano, Quality JSQC, Vol. 14, n° 2, octobre 1984. Article d'origine de Kano.

2. First Things First: Prioritizing Requirements par Karl E. Wiegers