La moyenne de la somme des points des scénarios utilisateurs (“user stories”) terminés par l’équipe à la fin de chaque itération (ou cycle) représente la vélocité moyenne d’une équipe.
Mais que représentent ces points exactement? Car en Agilité, il existe deux types de points à ne pas confondre : les points de valeur et les points de complexité. Ce sont ces derniers qui permettent à l’équipe de calculer sa vélocité. Ils sont estimés par l’équipe durant l’événement de planification en début d’itération.
Un point de complexité, c’est quoi exactement? Par son nom, vous vous dites : la complexité, c’est évident! Il s’agit pourtant de plus que cela. Il s’agit en fait de la complexité, mais également du temps de réalisation et du risque liés à un scénario pour l’équipe. Afin d’englober les trois facettes, plusieurs comme Mike Cohn dans cet article parlent plutôt de points d’effort. Par exemple, à risques égaux, un scénario très complexe, mais qui requiert peu de temps pour être effectué pourrait avoir le même nombre de points qu’un scénario simple, mais qui serait long à réaliser. Pourquoi? Car c’est l’effort total devant être déployé pour terminer le scénario qui est évalué et non un seul de ces aspects.
Communément, on utilise un jeu de cartes composé de la suite de Fibonacci pour évaluer la complexité en faisant une partie de Planning PokerMD.
Certains utilisent d’autres méthodes d’évaluation comme l’estimation par similitude ou encore les grandeurs de tee-shirt (XS, S, M, L, XL, XXL). L’important, c’est que cela parle à votre équipe et que vous soyez à l’aise avec la méthode que vous utilisez.
Finalement, le nombre de points que récolte une équipe n’est pas une mesure de comparaison avec les autres équipes. Ce nombre est propre à chaque équipe. Plusieurs facteurs entrent en ligne de compte dans la variation de la vélocité d’une équipe :
- Le niveau de compétence des joueurs de l’équipe;
- Leur expérience;
- Leur connaissance du domaine d’affaires;
- Leurs méthodes de travail;
- Les bloqueurs et risques rencontrés.
On ne peut donc pas dire qu’une équipe qui a une vélocité moyenne de 40 points est meilleure qu’une équipe qui en a une de 25. Le bon réflexe du gestionnaire ou du Scrum Master est plutôt de se questionner sur ce qui empêche l’équipe qui a 25 points d’avoir une vélocité de 40 ou plus et de faire ce qui est possible pour arriver à augmenter la vélocité de celle-ci tout en gardant un rythme de travail soutenu et soutenable.
Le Planning PokerMD en 7 étapes
Le Planning PokerMD est donc la technique Agile la plus commune qui permet de déterminer le nombre de points de complexité évalués pour chaque scénario lors de la planification de l’itération.
Une partie de Planning PokerMD se déroule de la façon suivante :
- Durant la période de planification au début de l’itération, le Product Owner (PO) explique les scénarios utilisateurs à l’équipe.
- Pour chacun des scénarios, les membres de l’équipe posent leurs questions au PO afin de s’assurer qu’ils comprennent bien le besoin exprimé.
- Une fois que tout le monde a posé ses questions, que les risques semblent connus et que le scénario et son niveau de complexité semblent également bien compris par tous, on passe à l’évaluation de la complexité en passant au vote en utilisant un jeu de cartes basé sur la suite de Fibonacci.
- Mais comment savoir quelle carte choisir? En se donnant des étalons : un scénario évalué à 5 points devrait normalement être approximativement deux fois plus complexe qu’un scénario évalué à 2 points.
- Mais que fait-on lorsque nous n’avons pas d’étalons de comparaison possibles? On évalue selon les meilleures connaissances de l’équipe à ce moment précis. C’est pour cela qu’au début de la mise en place de Scrum ou d’Agile Lean, cela prend quelques itérations pour stabiliser la vélocité, mais également pour connaître ces étalons.
- Tout le monde tourne sa carte en même temps afin de divulguer son choix (c’est bien important afin que le vote des uns n’influence pas celui des autres).
- Parfois, il y a un consensus immédiat, parfois non. Si consensus il y a, on note le nombre de points attribués et on passe au scénario suivant. Sinon, ceux qui ont donné le nombre de points le plus élevé et le moins élevé expliquent leur choix à l’équipe.
- À la suite de ces explications, une discussion peut s’ensuivre et on tente de rallier tout le monde à une valeur de complexité commune.
- Si l’on n’arrive pas à l’unanimité, les discussions se poursuivent et on reprend les étapes 4 à 7 jusqu’à ce qu’il y ait consensus.
Les gens qui font la promotion et qui utilisent le Planning PokerMD y voient généralement les bienfaits suivants :
- Cela favorise la collaboration en engageant toute l’équipe.
- Cela crée un consensus sur l’estimation plutôt que sur le simple avis d’un « champion ».
- Cela permet d’exposer les problèmes et les risques dès la présentation du scénario et d’en discuter.
- Ce ne sont pas les dirigeants qui votent, mais ceux qui auront à réaliser les scénarios.
- Les discussions sur la mise en œuvre sont interrompues avant de creuser trop profond.
6 Commentaires
Est-ce vraiment correct de comparer la vélocité de deux équipes différentes? Si une équipe a une vélocité de 40 points et l’autre de 25 points, est-il possible que la “valeur” de leurs points ne soit pas la même? Par exemple, pour la première équipe un story de 2 points pourrait avoir été évaluée à 1 point par l’autre équipe, d’où la différence de vélocité. Ça reste subjectif et je crois que ça dépend de l’équipe qui évalue.
Bonjour Julie,
Je suis tout à fait d’accord avec toi. La phrase “On ne peut donc pas dire qu’une équipe qui a une vélocité moyenne de 40 points est meilleure qu’une équipe qui en a une de 25” voulait justement exprimer ceci.
On peut toujours se questionner à savoir comment augmenter sa vélocité (ce qui est sain selon moi), mais jamais parce que l’on veut être le “voisin gonfable” d’une autre équipe. Malheureusement c’est souvent le cas chez certains gestionnaires… Le paraître prend souvent le dessus sur la vraie question, c’est-à-dire de ramener cela plutôt à l’équipe et d’encourager la réflexion afin de voir ce qui nous bloque (faire la guerre aux bloquants) et nous empêche d’augmenter notre vélocité.
Bonjour,
quel est le meilleur moyen d’apprécier un gain de vélocité grace å l’instauration d’un nouvel outil de travail sensé rendre les taches plus rapide?
Comment appréhender la différence de niveau qu’on va trouver au sein d’une même équipe entre un senior, qui connait parfaitement l’application sur laquelle il doit intervenir et qui va considérer que la fonctionnalité à chiffrer et simple à réaliser, puis estimer son cout à 1 point ET un junior qui va l’estimer à 13 points.
Après explications, arrangements, discussion, on tombera peut être sur un résultat final de 6 et si le développement est réalisé par le senior, il va avoir un paquet de temps libre (s’il ne s’est pas trompé dans ses estimations) alors que si c’est qui s’y colle, il risque d’être sous pression…
Donc pour une équipe ‘cohérente’ techniquement, ça peut être bien. Pour une équipé hétérogène en revanche, j’ai du mal à voir…
Bonjour Thierry,
Je suggère d’appréhender cela dans l’optique que l’estimation en point d’effort est relative par rapport à d’autre fonctionnalités. Donc la discussion devrait permettre d’attribuer un poids d’effort avec des fonctionnalités connues similaire. L’effort devient donc indépendant de la personne qui réalisera le travail. En conséquence la vélocité de l’équipe sera affectée en fonction de la personne qui réalisera la fonctionnalité.
Est-ce que cela répond à ton interrogation?
Bonjour,
Merci pour ce partage et vos questions.
Ma réponse arrive tardivement par rapport à l’age du post.
Je répondrais à Thierry que c’est la squad qui a 6 points et que le senior doit aider ses camarades. En conséquence, il peut faire ses stories à 1pt et passer x points à aider ses collègues.
Une moyenne représente un bon compromis, ne pensait pas individuellement mais en équipe !
Cordialement,
Mickaël