Planification de sprint

De Mitch Lacey.Propriétaire, Mitch Lacey & Associates, Inc, un société de conseils spécialisée dans les adoptions et améliorations 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.Cela peut vous aider à passer de la définition de priorités approximatives de votre journal des travaux en souffrance à un classement précis qui pèse 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

• Modèle Kano de la satisfaction client

• Jeux d'innovation

  • Nettoyer l'arborescence de produit

  • Acheter une fonctionnalité

• Poids relatifs – Karl Weigers

• Conclusion

Pour assurer le bon fonctionnement de votre équipe agile, vous devez classer les éléments dans votre journal des travaux en souffrance du produit par ordre de priorité, puis mettre à jour ces priorités à mesure que le projet avance.Tous les journaux des travaux en souffrance du produit doivent être classés par ordre de priorité en fonction de la valeur commerciale et du risque.En identifiant cet ordre de priorité, votre équipe peut mieux se concentrer sur les fonctionnalités qui comptent le plus dans la réussite de votre produit.Un journal des travaux en souffrance bien ordonné et hiérarchisé est utile non seulement pour la satisfaction de l'équipe et des clients mais aussi pour la base de votre entreprise.Pour des informations sur les journaux des travaux en souffrance, consultez Génération et la gestion du journal des travaux en souffrance du produit, Créer un journal des travaux en souffrance ou y ajouter des éléments et Nettoyer et estimer le journal des travaux en souffrance.

Lorsque vous organisez et classez par priorité votre journal des travaux en souffrance du produit, vous devez prendre en compte de nombreux facteurs et être en mesure de justifier vos décisions.Lorsque vous démarrez avec un journal des travaux en souffrance du produit brut, le processus peut sembler presque écrasant.Heureusement, vous ne devez pas trier à la perfection chaque élément dans votre journal immédiatement.Dans Estimation, je décris une technique appelée « Le grand mur », qui est un moyen efficace d'estimer rapidement un journal des travaux en souffrance du produit brut et de travailler avec les parties prenantes pour arriver à une priorité approximative.

Cette priorité approximative est un bon point de départ et peut convenir à votre situation.Toutefois, dans certains cas, vous pouvez affiner ces priorités ou obtenir un journal des travaux en souffrance classé par ordre de priorité de manière plus scientifique.Pour ce faire, de nombreuses techniques sont disponibles.Dans l'article suivant, je 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.Cela peut vous aider à passer de la définition de priorités approximatives de votre journal des travaux en souffrance à un classement précis qui pèse d'une manière satisfaisante le risque, l'importance et la satisfaction client.

Modèle Kano de la satisfaction client

Le modèle Kano de la satisfaction client a été développé dans les années 1980 par le professeur Noriaki Kano de l'Université de Tokyo Rika.Son modèle fournit un modèle de classement simple qui distingue les attributs essentiels et les différencie.Approche basée sur un questionnaire, le modèle est un moyen performant de visualiser les caractéristiques du produit et de stimuler le débat au sein de l'équipe de conception.

Au sein de Kano, nous posons une série de questions sous deux formes différentes : fonctionnelle et dysfonctionnelle.Par exemple, supposons que nous interrogeons les clients sur un système de navigation GPS applicable aux voitures.Nous posons d'abord la forme fonctionnelle de la question :

• Comment vous sentiriez-vous si cette voiture avait un système de navigation GPS ?

Nous limitons les réponses aux réponses suivantes :

• Je la voudrais de cette façon

• Je m'attendrais à ce qu'elle soit de cette façon

• Je suis neutre

• Je pourrais vivre avec de cette façon

• Je ne l'aimerais vraiment pas ainsi

Pour cet exemple, disons que nos clients fictifs ont répondu par « Je l'aime de cette façon-là »

Nous posons ensuite la forme dysfonctionnelle de la question :

• Comment vous sentiriez-vous si cette voiture n'avait pas de système de navigation GPS ?

Nos clients fictifs peuvent choisir parmi les réponses répertoriées.Toutefois, la réponse peut souvent être, et est généralement, différente.Pour cet exemple, supposons que nos clients fictifs ont répondu « Je le souhaitais de cette façon-là » dans le formulaire dysfonctionnel relatif à la question.

Lorsque nous faisons cela pour un projet réel, nous pouvons poser cette liste de questions à plusieurs groupes de clients, autrement dit, plusieurs ensembles de personnes qui représentent différentes fonctions de l'organisation client.Vous pouvez avoir un groupe marketing, un groupe de comptabilité, un groupe de fabrication, et ainsi de suite.À des fins de compréhension du modèle, imaginons que nous posons simplement un problème relatif à un seul groupe de clients.Après avoir compilé notre paire de réponses (les réponses à la formulation fonctionnelle et dysfonctionnelle), nous la mappons sur une grille, comme illustré dans le tableau 1.

Tableau 1 – Mappage Kano

Notez que, dans notre exemple, nos clients fictifs ont répondu comme à la question fonctionnelle et attendre à la question dysfonctionnelle.Lorsque nous mappons cette paire à la grille, nous pouvons voir que l'intersection de ces deux attributs est un E, comme l'indique le carré mis en surbrillance en jaune.Examinons ce que cela signifie pour notre journal de travaux en souffrance classé par ordre de priorité.

• E = Exciters.Ce sont des fonctionnalités que le client n'attendait pas. Elles permettent de réellement différencier un produit de ses concurrents.Il est difficile de les identifier, en particulier au début, car il est difficile de proposer des questions qui suscitent des fonctionnalités intéressantes.Pour cette raison, les excitateurs ont tendance à effectuer une émergence et une levée en priorité au fil de la progression du projet et de l'arrivée des commentaires des clients.

  • Les clients tirent une grande satisfaction de ces fonctionnalités et sont disposés à payer un supplément de prix pour les obtenir.Par exemple, l'iPod d'Apple a enchanté les clients par sa capacité intuitive à faire pivoter un contenu par rapport à l'orientation de l'écran.L'absence de cette fonctionnalité n'aurait toutefois pas diminué la satisfaction étant donné que le client ne s'y attendait pas.

  • Dans notre exemple, avoir la navigation GPS est une fonctionnalité fantastique.L'exploration de cette fonctionnalité, au moins au niveau du point de réception des commentaires client, doit relever d'une priorité relativement élevée.

• B = Ligne de base.Le produit doit proposer ces fonctionnalités.Ce sont des fonctionnalités incontournables et prioritaires.

  • Quelle que soit la façon dont ces attributs de base sont exécutés, le client reste neutre vis-à-vis du produit.Un traitement de texte, par exemple, doit contenir les fonctions « Créer un document » et « Enregistrer un document ».C'est le minimum.

  • Si nous avions interrogé notre groupe de clients sur les ceintures de sécurité, la plupart des personnes répondraient qu'elles s'attendent à ce qu'une nouvelle voiture soit équipée de ceintures de sécurité et qu'elles n'apprécieraient pas qu'elle n'en soit pas équipée.Si nous mappions ces deux réponses dans la grille, nous constaterions que les ceintures de sécurité sont une fonctionnalité de ligne de base (b)incontournable.

• L = Linéaire.Également appelées exigences de performances, les fonctionnalités linéaires ont une corrélation directe avec la satisfaction des clients.Au niveau de la priorité, elles sont situées juste en dessous des fonctionnalités de base, mais elles doivent être correctement évaluées par rapport à leur coût.

  • Les fonctionnalités accrues ou la qualité d'exécution augmentent la satisfaction client.Une fonctionnalité réduite diminue la satisfaction.

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

• I = Indifferent.Ces fonctionnalités sont moins importantes pour le client et, de ce fait, doivent être moins importantes pour le produit.Elles risquent de retourner peu, ou même aucune, valeur commerciale.

Le tableau 1 illustre également Q et R.

• Q : Question : la question est probablement incorrecte ou la réponse est suspecte.

• R : Inverser : la combinaison des réponses ne calcule pas.Prenez le système de navigation GPS : si un utilisateur répond qu'il s'attend à ce qu'il soit là mais qu'il aime également quand il n'y est pas, il s'agit d'une réponse R.

Si une paire de réponses est évaluée par Q ou R, vous devez examiner les problèmes ou les paires de réponses plus profondément.

Jeux d'innovation

Innovation Games sont des outils qui vous aident à développer une étude de marché primaire.Avec ces outils, les clients jouent à des « jeux » en vue de générer des commentaires et des avis sur un produit ou un service.Luc Hohmann a créé plus de 12 de ces jeux dans et les décrit dans son livre, Innovation Games, qui est un grand ajout à toutes les bibliothèques.Mes deux jeux préférés pour obtenir un journal de travaux en souffrance classé par ordre de priorité sont Prune the Product Tree et Buy a Feature, que Luc décrit dans cet extrait de cet ouvrage (utilisé par autorisation) :

Nettoyer l'arborescence de produit

Arborescences Prune de jardiniers pour contrôler leur croissance.Le nettoyage est parfois artistique, et nous obtenons des arbustes façonnés comme des animaux ou des formes abstraites intéressantes.La plupart du temps, le nettoyage est destiné à générer une arborescence équilibrée qui produit des résultats de grande qualité.Le processus ne traite pas de « coupe » mais de « mise en forme ». Utilisez cette métaphore pour créer le produit que les clients désirent.

The Game

Commencez par dessiner une grande arborescence sur un tableau blanc ou des feuilles blanches ou imprimez une image graphique d'arborescence sous la forme d'un poster grand format.Les grosses branches représentent des zones de fonctionnalités importantes dans votre système.Le bord de l'arborescence (ses branches les plus éloignées) représente les fonctionnalités disponibles dans la version actuelle.Entrez de nouvelles fonctionnalités potentielles de plusieurs fiches, idéalement façonnées comme des feuilles.Demandez à vos clients de placer les fonctionnalités souhaitées autour de l'arborescence, en définissant la phase suivante de croissance.Structurent-elles une arborescence qui augmente de façon équilibrée ?Est-ce-qu'une branche, par exemple une fonctionnalité principale du produit, obtient la partie de la croissance ?Est-ce-qu'un aspect peu employé de l'arborescence devient plus fort ?Nous savons que les racines d'une arborescence (votre infrastructure de prise en charge du client) doivent s'étendre au moins jusqu'à votre écran.Et les vôtres ?

Arborescence de produit – Hohmann

Pourquoi cela fonctionne

Vous et vos clients savez que les fonctionnalités varient en termes d'importance.Par conséquent, nous avons tendance à vouloir déployer nos efforts autour des fonctionnalités les plus importantes (celles qui fournissent la plus grande valeur aux clients).Malheureusement, cela signifie parfois que nous consacrons trop peu d'efforts aux fonctionnalités requises pour terminer le produit.Le jeu Nettoyer l'arborescence de produit permet à vos clients de participer à la prise de décision en examinant l'ensemble des fonctionnalités du produit d'une manière holistique.

Acheter une fonctionnalité

Quelle fonctionnalité persuadera les clients d'acheter votre produit ?Quelle fonctionnalité entraînera la mise à niveau des clients ?Quelle fonctionnalité rendra les clients si heureux qu'ils ignoreront ou tolèreront les fonctionnalités qu'ils souhaitent que vous résolviez ou retiriez ?

Les planificateurs de produit discutent sans cesse de ceci et d'autres types de questions.Le choix du jeu de fonctionnalités approprié à ajouter à une version finale marque souvent la différence entre l'échec à court terme ou la réussite à long terme.Malheureusement, un trop grand nombre de planificateurs de produit prennent cette décision sans impliquer les personnes les plus concernées, à savoir leurs clients.Le jeu Acheter une fonctionnalité améliore la qualité de cette décision en demandant à vos clients de vous aider à le faire.

Acheter une fonctionnalité – Sterne

The Game

Créez une liste de fonctionnalités potentielles et attribuez un prix à chacune.Comme dans un produit réel, le prix peut être basé sur les coûts de développement, la valeur pour le client, etc.Bien que le prix puisse être le prix réel que vous comptez facturer pour la fonctionnalité, cela n'est généralement pas nécessaire.Les clients achètent des fonctionnalités qu'ils souhaitent intégrer dans la prochaine version de votre produit à l'aide de l'argent de jeu que vous leur offrez.Assurez-vous que certaines fonctionnalités ont un prix suffisamment élevé pour empêcher les clients de les acheter.Encouragez les clients à acquérir les fonctionnalités particulièrement importantes et/ou coûteuses.Cela permettra d'établir avec les clients le niveau d'importance des fonctionnalités.

Pour ce jeu, le nombre idéal de client par groupe est entre quatre et sept, afin de pouvoir créer plus de possibilités pour que les clients fassent des acquisitions via la négociation.Contrairement au jeu Emballage du produit, le jeu Acheter une fonctionnalité est basé sur la liste des fonctionnalités susceptibles d'être dans la feuille de route de développement.

Pourquoi cela fonctionne

Les planificateurs de produit tombent souvent dans le piège de penser que les clients ont des priorités bien définies quant au produit.C'est le cas pour certains.La majorité des clients ne le font pas.Lorsqu'on leur présente un jeu d'options, de nombreux clients diront simplement « Je les veux toutes. » et feront reposer sur vous la responsabilité de classer par priorité leurs requêtes.Les chefs de produit collectent aussi souvent les priorités des fonctionnalités en travaillant individuellement avec les clients et, au cours du processus, et peut-être sans même s'en rendre compte, prennent une fois de plus la responsabilité de hiérarchiser les fonctionnalités.En encourageant le travail de groupe parmi les clients et en leur attribuant un nombre limité de ressources, vous leur donnez la possibilité de classer par priorité leurs souhaits dans le cadre du groupe.Mais ce n'est pas ce qui est magique.La magie réside dans la structure des conversations afin que vos clients négocient entre eux des fonctionnalités spécifiques.C'est cette négociation qui améliore votre conception de ce que vos clients souhaitent réellement.

Poids relatifs – Karl Weigers

Une autre méthode excellente pour la priorité est la pondération relative, de Karl Weigers introduite en 1999.Cette méthode fournit non seulement un mécanisme pour classer des spécifications selon l'entrée d'utilisateur et les commentaires, mais inclut également un jugement expert de l'équipe.Comme Kano et Innovation Games, Relative Weighting permet au propriétaire du produit de mieux estimer les fonctionnalités à implémenter et dans quel ordre de priorité.

La première étape consiste à assigner un poids à l'avantage relatif d'une fonctionnalité.Pour les utilisateurs, l'avantage est le fait de disposer de la fonctionnalité dans le produit fini.Ensuite la pénalité relative doit être affectée.Pour les utilisateurs, la pénalité est la conséquence de ne pas avoir les fonctionnalités dans le produit fini.(L'évaluation des avantages et des pénalités parvient au même résultat que la formulation fonctionnelle et dysfonctionnelle de la question de la méthode Kano). Les pondérations sont des nombres arbitraires qui représentent la façon dont votre société évalue les avantages et les risques des fonctionnalités.c'est très similaire à la façon dont un professeur détermine la mesure dans laquelle le travail à domicile, la participation, les questions et les tests déterminent l'évaluation complète. Cela varie d'un professeur à l'autre.Si vous décidez que les avantages sont supérieurs aux pénalités, faites en sorte que la proportion soit supérieure à la pénalité en fonction du taux d'ajustement qui vous semble approprié.Si vous décidez que les pénalités sont supérieures aux avantages, ajustez la pondération en conséquence.Dans l'exemple du tableau 2, nous avons attribué à l'avantage une pondération relative de 2 et à la pénalité une pondération relative de 1, ce qui signifie que l'avantage aura un facteur supérieur pour déterminer la priorité finale.

De la même façon, nous déterminons le poids du pourcentage des coûts et du pourcentage des risques.Dans l'exemple suivant, le risque n'était pas très inquiétant pour le projet et donc il a été attribué une pondération donnée de 1 au pourcentage de coût et une pondération de 0,5 au pourcentage de risque.(Bien que l'avantage et la pénalité soient pondérés avant le calcul du pourcentage de valeur, le coût et le risque sont pondérés sous forme de pourcentages). Si vous avez un projet à haut risque, vous devez évaluer un risque plus élevé que le coût.

Maintenant que les pondérations sont définies, nous demandons aux utilisateurs d'évaluer l'avantage relatif et la pénalité relative de chaque fonctionnalité.Chaque avantage et chaque pénalité sont évalués sur une échelle définie - Weigers recommande une échelle allant de 1 à 9, mais vous pouvez en choisir une autre à condition d'être cohérent.L'avantage relatif est la valeur que la fonctionnalité fournit ; la pénalité relative est l'impact négatif potentiel de ne pas faire la fonctionnalité.

Par exemple, supposons que la fonctionnalité « Rendre le widget conforme aux réglementations Sarbanes-Oxley » soit possible. Il n'y a quasiment aucun avantage pour les utilisateurs, mais la pénalité relative à l'activité est grande - ne pas le faire pourrait mettre la société hors marché.Ainsi, on pourra voir une note de 1 ou 2 pour l'avantage relatif et une note de 8 ou 9 pour la pénalité relative.

Dans l'exemple suivant, les utilisateurs ont donné 5 à l'avantage relatif de la fonctionnalité « État de requête d'une commande fournisseur ».La pénalité associée était évaluée à 3.Pour dériver la valeur totale de cette fonctionnalité, nous multiplions les deux nombres par leurs poids relatifs et les ajoutons :

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

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

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

Lorsque nous obtenons la valeur relative totale et le pourcentage de valeur pour les fonctionnalités, nous nous éloignons des utilisateurs pour obtenir l'analyse de l'équipe.Nous demandons à l'équipe d'estimer le coût relatif lié à l'implémentation de chaque fonctionnalité à l'aide de la même échelle.Karl Weigers explique que « les développeurs estiment les évaluations de coûts en fonction de facteurs tels que la complexité de spécification, l'étendue du travail d'interface utilisateur requise, la capacité potentiel de réutiliser des conceptions existantes ou le code, et les niveaux de test et de ocumentation nécessaires. »

Après avoir estimé le coût relatif, nous estimons le risque relatif.Là encore, Weigers déclare, « Les développeurs estiment le degré relatif du risque technique ou d'un autre risque associé à chaque fonctionnalité sur une échelle allant de 1 à 9.Une estimation de 1 signifie que vous pouvez le programmer dans votre sommeil, tandis qu'une valeur de 9 indique de sérieux problèmes de faisabilité, de disponibilité du personnel avec les compétences nécessaires ou d'utilisation d'outils et de technologies qui n'ont pas encore fait leurs preuves ou inconnus.La feuille de calcul calculera pourcentage de risque total provenant de chaque fonctionnalité. »

Après avoir noté les valeurs pour l'avantage, la pénalité, le coût et le risque relatifs, nous additionnons chaque colonne.Les totaux seront utilisés pour calculer les pourcentages.

• Pourcentage de valeur totale : divisez la valeur de somme des avantages et pénalités relatifs par la somme totale en bas.Dans l'exemple suivant, cela donne 13 / 154 = 8 %.

• Pourcentage relatif de coût : divisez la valeur relative des coûts par toute la somme relative du coût en bas.Dans l'exemple suivant, cela donne 2 / 42 = 4,8 %.

• Pourcentage relatif de risque : Divisez la valeur relative du risque par toute la somme relative de risque en bas.Dans l'exemple suivant, cela donne 1 / 33 = 3 %.

• Priorité : divisez le pourcentage de valeur par (pourcentage de coût * pondération de coût) + (pourcentage de valeur * pondération de la valeur).Dans l'exemple suivant, cela donnerait 8,4 % / ((4,8 % * 1) + (3 % * 0,5).Cela donne la valeur de priorité (1,345).

Après avoir obtenu les valeurs de priorité, nous trions la colonne de priorité dans l'ordre décroissant afin que les éléments de priorité la plus élevée figurent en haut.Lorsque des éléments sont ajoutés au journal des travaux en souffrance du produit ou que des informations supplémentaires sur un récit apparaissent, nous devons réévaluer la priorité.

En définitive, la feuille ressemble au tableau suivant :

En adoptant cette méthode, vous pouvez mieux comprendre les intervalles qui fonctionnent pour l'équipe et pour les parties prenantes.Cela permet également de mieux définir les discussions, car il peut être difficile de factoriser objectivement des éléments tels que l'avantage, la pénalité, le coût et le risque pour chaque fonctionnalité.

Weigers explique comment rapprocher davantage le modèle de votre réalité :

« Calibrez ce modèle pour votre propre usage à l'aide d'un ensemble de spécifications ou de fonctionnalités achevées d'un produit précédent.Ajustez les facteurs de pondération jusqu'à ce que la séquence de priorité calculée soit conforme à votre évaluation post-facto de l'importance réelle des spécifications dans votre jeu de tests.Ce modèle peut également vous aider à prendre des décisions de compromis lorsque vous évaluez les nouvelles spécifications proposées.Estimez leur priorité à l'aide du modèle pour connaître leur correspondance par rapport aux spécifications existantes, afin que vous puissiez choisir une séquence d'implémentation appropriée.Toutes les mesures que vous pouvez prenez pour transférer la priorité des spécifications du domaine politique vers un objectif et une analyse améliorent la capacité du projet à fournir la fonctionnalité la plus importante de la séquence la plus appropriée ».

Karl Weigers a écrit deux ouvrages entré deux livres qui décrivent plus en détail la pondération relative : Software Requirements, Second Edition et More About Software Requirements: Thorny Issues and Practical Advice.

Si vous utilisez l'un de ces méthodes ou une autre technique, souvenez-vous que le journal des travaux en souffrance du produit est une opération active.Vous ne classez pas simplement le journal des travaux en souffrance une fois avant de le mettre de côté ; le reclassement par priorité est une partie attendue de la mise à jour d'un journal correct.Pour assurer la progression de votre projet, vous devez constamment réévaluer les récits, leur importance pour le projet, et la manière dont les nouvelles informations affectent le journal des travaux en souffrance.Vous devez supporter les douleurs pour conserver l'implication de vos clients et parties prenantes tout au long du projet.De plus, vous devez vous rappeler que l'évaluation d'un élément est essentielle pour déterminer sa priorité.Ne laissez pas vos journaux de travaux en souffrance périmer et disparaître.Investissez du temps et du travail dans l'alimentation et le nettoyage de votre journal des travaux en souffrance. Vous en verrez les effets non seulement dans le produit fini mais également dans votre résultat.

Voir aussi

Concepts

Effectuer une mise en route en tant qu'équipe

Planification et itérations Agile

Commentaires des parties prenantes de demande et de processus à l'aide de team Web access

Faire le suivi d'un travail et gérer le flux de travail

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   « Attractive Quality and Must-be Quality », Noriaki Kano, Quality JSQC, Vol.14, No.2, octobre 1984.Article d'origine de Kano.

2. http://www.processimpact.com/articles/prioritizing.html