Affinity Estimating : Une réunion structurée pour estimer les tailles de User Story en projet Agile

affinitye

En projet Agile, toute la planification se base sur l’estimation de la taille des User Story. Par ailleurs, la construction d’itérations équilibrées nécessite d’avoir des Story de taille suffisement petite. Quand le Product Backlog contient plusieurs dizaines voir quelques centaines de Story, estimer ces Story peut prendre un temps conséquent pour l’équipe. L’Affinity Estimating est une réunion structurée qui peut permettre, dans l’espace de 2 ou 3 heures de définir les tailles des Story d’un backlog de taille conséquente.

Qui doit participer ?

L’équipe, le Coach ainsi que le Product Owner et d’éventuels utilisateurs ou parties prenantes doivent être présentes. Les personnes présente du coté du Product Owner doivent connaître les Product Backlog suffisamment pour pouvoir donner à l’équipe les détails nécessaires.

Quelle durée ?

Une durée entre 2 à 3 heures doit être prévue.

Autres préparatifs

Les User Story du Product Backlog doivent être disponibles sous forme de cartes que l’on peut accrocher et déplacer sur un mur ou un tableau. Sur le tableau ou le mur de travail, une extrémité est marquée « Petite Story », et l’autre « Grande Story », de façon à ce que l’équipe identifie l’ordre dans lequel les Story sont sensées être triées. Par example, de gauche à droite de la plus petite à la plus grande.

Les étapes de la réunion

Etape 1 : Classification silencieuse

Le Product Owner fournit à l’équipe le Product Backlog par Packet à l’équipe. Les membres de l’équipes vont placer et déplacer les Story sur le mur une à une dans l’ordre de taille. Pendant cette exercice l’équipe ne discute pas entre elle, cependant elle peut obtenir de la part du Prodcut Owner ou des utilisateurs les clarifications nécessaires sur les Story. Cette étape se termine quand plus personne n’a envie de bouger des Story. Elle peut aussi être « Time-boxée », c’est à dire avoir une durée maximale pré-determinée, afin de maîtriser le temps de réunion. Une telle timebox peut être par exemple d’une heure.

Etape 2 : Discussion de l’équipe

A cette étape, chaque membre de l’équipe peux changer l’ordre des Story sur le tableau mais doit pour cela en discuter et le justifier auprès de ses collègues. Cette étape se termine quand plus personne n’a envie de bouger des Story.

Etape 3 : Mise en boite

Des colonnes sont tracées sur le tableau pour grouper les User Story par taille, chaque groupe ainsi crée contient les Story de la même taille dans l’échelle. L’échelle est celle définie par l’équipe, classiquement :

  • La suite de fibonacci : 1; 2; 3; 5; 8; 13 …
  • Les tailles : XS, S, M, L, XL
  • Deux puissance N : 2, 4, 8, 16 …

Etape 4 : Intervention du Product Owner et utilisateurs

L’équipe peut prendre une pause pendant que le Product Owner et autres utilisateurs présents marquent les Story dont il souhaitent rediscuter l’estimation avec une marque ou une couleur particulière.

Etape 5 : Discussion avec le Product Owner

L’équipe et le Product Owner se concentrent sur les Story les plus prioritaires pour affiner ou confirmer la première estimation de taille.

Finalisation

Au bout de cette étapes les Stories du Product Product backlog on été triées et ont une taille associée. Certaines peuvent rester trop floues pour être estimées, elles nécessiteront par exemple un « Spike », c’est à dire une étude exploratoire de 1 ou 2 jours pendant une itération, afin de lever les incertitudes et donner une estimation. D’autres seront d’une taille trop grosses pour être incluse dans une itération et devront être détaillées par le Product Backlog en plusieurs « Story » plus petites.

Les 3 symptômes des méthodes de gestion de projet inadaptées

Un outil de gestion de projet doit rester pour les membres de l’équipe un outil, et ne doit surtout pas devenir un fardeau. Bien souvent, ce n’est pas le cas et les équipes elles-mêmes ont du mal à diagnostiquer la situation. Ci dessous quelques signaux avant-courreurs qui devraient vous pousser à vous poser des questions sur les outils et méthodes que vous adoptez:

Symptome 1 : la multiplication des listes de taches

Quand l’outil de gestion de projet n’est pas suffisemment utile et pratique, les équipes commencent à multiplier les listes de taches à gauche et à droite. Cela peut se matérialiser entre autres par des liste de taches qui s’échangent dans des mails ou encore des fichiers de tableurs partagées en local ou sur le cloud.

Symptome 2 : la nécessité des relances pour la mise à jour.

La tenue à jour d’un outil se fait au fil de l’eau quand celui-ci est réellement utilisé pour s’organiser individuellement ou communiquer avec les autres. Quand ce n’est pas le cas, il y a toujours besoin de pousser pour tenir à jour le suivi, car c’est bien de cela qu’il s’agit.

Symptome 3 : la taches stagnantes

Personne ne porte d’intérêt réel à la pertinence du contenu d’un outil inutile. Des taches peuvent ainsi rester des mois sans avancer, tout simplement parce que personne ne les a comprises ou prises en compte, et ça ne les dérange pas le moins du monde que l’outil soit pollué d’informations périmée.

La solution qu’apporte Teamwall

S’inspirant des méthodes agiles Teamwall apporte une solution nouvelle en appliquant 3 principes simples :

  1. L’utilité : Un outil existe pour être utile à ses utilisateurs, Teamwall s’est donc concentré sur les fonctions qui aident les utilisateurs à s’organiser et à communiquer. Ainsi, pour s’organiser, chaque utilisateur peut facilement et rapidement identifier et gérer les taches qui le concernent. Et pour communiquer l’équipe partage en temps réel une vision sur l’état du projet et peut mener des standups efficaces même à distance.
  2. Le plaisir : L’utilisation de l’outil doit rester un plaisir : cela passe par le soin apporté à l’aspect visuel, par l’élimination des formulaires complexes au profits de textes simples éventuellement taggés et par des fonctions pratiques comme le partage des fichiers par glisser/déposer et l’interaction en temps réel.
  3. La souplesse : C’est l’utilisateur qui adapte son outil à ses besoin et non pas l’outil qui contraint l’utilisateur à son processus. Ainsi, dans Teamwall les utilisateurs peuvent en quelques clics créer des tableaux de notes privés, les personnaliser puis les partager, les adapter ou les retirer en fonction des besoins. Ce la permet de garder l’outil de gestion en cohérence avec les pratiques de l’équipe et de gérer les multiples micro plans d’action qui accompagnent souvent un projet.

Gantt Vs. Tableau de Notes ou les fausses prévisons Vs. le vrai état du présent

Le gantt représente une réalité projetée. Dans les projets à forte composante d’ingénieure comme l’informatique, on sait que cette prévision sera fausse, cela n’empêchera pas ceux qui regardent le planning de l’utiliser pour s’organiser et construire des stratégies.
Le tableau de note se concentre sur la représentation de la réalité présente avec le plus de précision possible : qu’avons nous fait, que sommes nous en train de faire que nous reste-t-il à faire.

On peut reprocher au tableau de notes de ne pas donner par lui même une projection du futur, la question est : vaut-il mieux avoir une fausse prévision ou un vrai état de la situation présente ? Pour les équipes elle même c’est plus le présent qui est important, pour les partenaires c’est plus la projection du futur qui est importante.

Vu sur la blogosphère : Les deux piliers du Toyota Way : l’Amélioration continue et le Respect des Hommes

… le Toyota Way a deux piliers : le Respect des Hommes (employés, partenaires ou autres), et l’Amélioration continue… Certes, on peut toujours utiliser quelques outils de lean (ex : kanban) pour réduire des coûts (réduction des les stocks dans le cas du kanban) et présenter les résultats des gains ici et là pour impressionner les collègues, visiteurs, les concurrents, les investisseurs ou la bourse mais cela ne s’appelle pas déployer du lean…

Les deux piliers du Toyota Way : l’Amélioration continue et le Respect des Hommes

Prise de décision dans les projets agiles

Dans tout projet il est question de faire des choix et des arbitrages. Par rapport à cela, les projets agiles ont certaines spécificités.

Les variables QCD revisitées

Classiquement, les choix dans un projet sont perçus au bout du compte comme un arbitrage entre les trois composante du tryptique QCD :

  • Qualité : La qualité ou le contenu du livrable (exemple nombre ou complexité des fonctions livrées).
  • Cout : Qui revient souvent à la quantité de ressource qu’il va falloir mobiliser sur un projet (nombre de développeurs, moyens financiers …).
  • Délais : Qui est la date de de livraison prévue.

Ainsi, améliorer la Qualité (Q) nécessite soit de mettre plus de ressource (donc un Cout supplémentaire) ou livrer plus tard (donc un Délais supplémentaire). Inversement, réduire le Cout (donc les ressources mobilisées) nécessiterait soit de réduire les fonctionnalités livrées (donc la Qualité) soit augmenter le Délais de livraison vu le manque de ressources. Ainsi de suite …

En projet classique toutes les variables sont considérées pour l’arbitrage, et souvent, on impactera d’abord le Délais, ensuite éventuellement le Cout et vraiment en dernier recours la qualité.

Les priorités QCD en projet Agile : la Qualité, variable de choix

En agile, les durées d’itérations sont fixées, la composante Délais n’est donc pas une variable d’ajustement sauf très rare exception. Cela a pour avantage de maintenir un synchronisme naturel à la fin de l’itération entre les équipes de développement et le reste de l’entreprise (équipes de test, déploiement, métier, communication …).

La composante Cout de son côté est souvent difficilement ajustable. En effet, en projet agile :

  1. La priorité est donnée au livrable par rapport à la documentation.
  2. L’interaction directe des membres prévaut par rapport aux processus et outils.

De fait la culture de l’équipe est relativement orale et met donc du temps à se transmettre aux nouveaux arrivants.

De plus, les équipes étant souvent auto-organisée, cela nécessite du temps pour se réorganiser en fonction des capacités de nouveaux arrivants.

La variable d’ajustement principale est donc souvent la Qualité autrement dit, la question revient souvent à une variante de : Que vas-t-on livrer ?

Les critères de décision en agile : la valeur et la capacité à livrer

Une fois la question posée, les réponses possibles sont analysées selon deux critères principaux :

  1. Quelle valeur ajoutée apporte tel ou tel choix à l’utilisateur (Valeur métier)
  2. A quel point les informations nécessaires pour livrer cette valeur sont disponibles.

Parmi les options suffisamment précise et réalisables on choisira donc celle qui apporte le plus de Valeur au métier.

Le droit à l’erreur

En projet agile, le changement est la règle et non pas une exception, de fait on se donne le droit de se tromper et de changer de cap, de fait la décision peut se prendre avec un certain niveau d’incertitude. Cependant, il convient dans ce cas là de se donner les moyens de détecter son erreur le plus tôt et la convertir en apprentissage dans le cadre de l’amélioration continue.

En conclusion

Les choix de projet agile reviennent souvent à redefinir le périmètre ou les détails du livrable (variable Qualité), ce choix doit se faire essentiellement en regardant la valeur métier et la capacité à réellement livrer cette valeur. Enfin, il n’est pas une exception de devoir éventuellement changer d’avis plus tard, l’important est de transformer les erreurs en apprentissage.