Optimiser votre vélocité agile en estimant vos story points

Si vous avez déjà emprunté les routes pour aller à Paris, vous savez que le temps nécessaire pour aller de Versailles à l'arc de Triomphe est soumis à un certain nombre de facteurs, dont le trafic, la météo, les travaux, l’heure de la journée et les autres conducteurs. Ces quelque 15 km de trajet peuvent aussi bien prendre 20 minutes que 4 heures.

Les éléments de votre backlog produit Scrum sont soumis à tout autant de variables, ce qui rend souvent la planification agile aussi exaspérante que les embouteillages de Paris.

Et c’est un énorme problème. Si vous ne parvenez pas à estimer de manière précise et cohérente le temps nécessaire ou votre vélocité agile au cours de votre planification, vous risquez de ne pas respecter les délais, d’être confronté à des goulets d’étranglement, des obstacles, des dérives et parfois même de faire échouer votre projet.

La bonne nouvelle est qu’il existe un meilleur moyen d’estimer le temps nécessaire lors de votre planification agile : les story points.

Inconvénients des autres méthodes d’estimation du temps dans les projets agiles

Avant de nous pencher sur les avantages du calcul des story points, examinons d’autres méthodes d’estimation du temps utilisées dans la planification agile.

De nombreuses équipes établissent une estimation de leurs projets et éléments par heure, puis attribuent un nombre total d’heures par sprint. Cependant, si nous reprenons l’analogie du trajet en voiture, cette pratique est similaire à celle qui consiste à considérer uniquement la distance kilométrique sans tenir compte des autres facteurs.

Une autre méthode d’estimation est la technique du « jour idéal ». Chaque journée de travail inclut des échanges par e-mail, des chats et des réunions, ce qui signifie que vos développeurs ne seront pas disponibles pour travailler pendant 8 heures chaque jour, même si ces activités font partie de leur mission. L’inconvénient de cette méthode d’estimation est qu’elle repose toujours sur les heures, et non sur l’effort déployé.

En quoi consistent les story points ?

Comment l’estimation des story points peut-elle donner à votre équipe une idée plus précise du temps nécessaire pour réaliser vos user stories ?

Avec les story points, les équipes prennent en compte le degré d’effort et de complexité pour attribuer une valeur chiffrée à chaque élément du backlog produit. Les story points permettent d’avoir une vision beaucoup plus complète que la prise en compte d’un seul facteur, le temps.

L’estimation des story points comprend trois facteurs principaux :

• Risque : le risque d’un projet ou d’un élément spécifique inclut les demandes imprécises, la dépendance à l’égard d’un tiers ou les changements en cours de tâche.
• Complexité : ce facteur correspond au degré de difficulté que présente le développement de la fonctionnalité.
• Répétition : ce facteur est déterminé par le degré de connaissance de la fonctionnalité par le membre de l’équipe et le caractère monotone de certaines tâches de développement.

En s’appuyant sur les trois points ci-dessus, votre équipe peut planifier ses sprints avec plus de précision, prévoir des marges d’incertitude, mieux estimer les difficultés et éviter de se retrouver trop contrainte par ses engagements temporels. Les story points permettent d’assurer la cohérence non seulement entre les équipes, mais aussi entre les services.

3 étapes pour estimer les story points agiles

Suivez ce processus pour planifier vos sprints avec plus de précision, fixer des attentes réalistes et accélérer la réalisation de vos projets.

1. Utiliser les nombres de la suite de Fibonacci

Il est tentant d’attribuer des éléments avec une échelle linéaire, mais ces nombres entiers ne sont pas assez différenciés pour définir clairement une estimation.

Vous avez probablement rencontré ce problème chez le médecin avec la fameuse échelle de la douleur. Si le chiffre 1 correspond à « tout va bien » et que le chiffre 10 correspond à une douleur si intense que vous avez l’impression de mourir, que représente le chiffre 4 ? De plus, comment distinguer 4 de 5 ? Et où se situe un calcul rénal sur l’échelle si vous n’avez jamais ressenti de douleur intense auparavant ?

Les nombres de la suite de Fibonacci éliminent ces petits écarts. Si vous n’êtes pas familier avec le sujet, la suite de Fibonacci est une série de nombres dans laquelle chacun est la somme des deux nombres précédents : 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.

Dans un cadre agile, la séquence est généralement modifiée en 0,5, 1, 2, 3, 5, 8, 13, etc. Grâce à ces nombres, il est beaucoup plus facile de décider si un élément correspond à 3 ou à 5 story points Fibonacci.

2. Déterminer une matrice

Une fois que vous avez décidé d’utiliser la suite de Fibonacci, vous devez déterminer une base de référence pour chaque story point. Par exemple :

1 = Ajouter un nouveau produit à un menu déroulant

2 = Ajouter un suivi de commande pour les utilisateurs connectés

3 = Ajouter un système d’avis au site Web

5 = Ajouter un forum au site

8 = Mettre l’ensemble du site en conformité avec le RGPD et le CCPA

Votre valeur de départ dans cette matrice est de 1, ce qui correspond au niveau de risque, de complexité et de répétition le plus faible possible. Cette matrice permet de mesurer plus précisément les efforts à fournir ; tenez-en compte plutôt que de vous contenter d’évaluer vos éléments en fonction du facteur temps.

3. Jouer votre planification au poker

Le poker aide les équipes à se mettre d’accord sur le nombre approximatif de story points pour chaque élément. Voici les règles du jeu :

1. Lors d’une réunion de sprint planning, chaque développeur et testeur reçoit un ensemble de cartes, chacune représentant un nombre de la suite de Fibonacci.
2. Un élément du backlog est soumis à une discussion afin que l’équipe puisse poser des questions et demander des précisions sur les fonctionnalités.
3. Lorsque l’échange est terminé, chaque développeur et testeur choisit à l’abri des regards la carte qui illustre le mieux son estimation.
4. Une fois que tout le monde est prêt, les participants révèlent leur carte en même temps. Si un consensus est atteint, il est temps de passer au prochain élément du backlog. Si les estimations varient, les responsables débattent jusqu’à parvenir à un accord.

Lors du planning poker, il est utile d’avoir une matrice remplie à portée de main pour que les participants puissent s’y référer afin de garantir une plus grande cohérence entre les tâches. Il est également judicieux de fixer une limite maximale de story points (13, par exemple). Si vous estimez qu’une tâche dépasse cette limite, elle doit être divisée en plusieurs éléments plus petits. De même, si une tâche est inférieure à 1, elle doit être intégrée à une autre.

À ce stade, lors de votre réunion de sprint planning, les éléments du backlog produit peuvent être classés par ordre de priorité et répartis entre les membres de l’équipe en fonction de leurs capacités de travail.

Comment estimer votre vélocité agile ?

Vous vous demandez peut-être combien de story points une équipe peut réaliser au cours d’un sprint. C’est ce qu’on appelle la vélocité agile, et malheureusement, il n’y a aucun moyen de la déterminer avant la fin de votre première itération.

Au cours du sprint suivant votre première réunion de planification des story points, notez le nombre de points que vous avez réalisés. Ce résultat peut ensuite être utilisé pour déterminer le volume raisonnable de story points que votre équipe peut effectuer au cours d’un sprint. Vous serez alors en mesure d’estimer combien de cycles de sprint prévoir pour un projet.

Si vous utilisez un tableau Scrum ou Kanban, il suffit de regarder la colonne « Terminé » à la fin de votre sprint et de totaliser le nombre de story points. Au fil du temps, vous pourrez faire la moyenne de plusieurs semaines de données pour estimer plus précisément votre vélocité de sprint agile.

Continuer d’améliorer vos estimations en fonction des sprints précédents

Le premier sprint après avoir adopté la technique des story points ne se déroulera pas parfaitement. Et c’est tout à fait normal. Avertissez votre équipe en amont afin d’éviter que la frustration ne prenne le dessus sur le processus.

Lors de votre prochaine réunion de sprint planning, demandez à votre équipe ce qui s’est bien passé, ce qui s’est mal passé et ce qui peut être amélioré. Il vous faudra peut-être ajuster votre matrice initiale pour mieux estimer les éléments à venir. Et cette matrice devra être ajustée jusqu’à ce que votre équipe parvienne à estimer efficacement l’effort demandé par chaque tâche.

Le développement agile étant un effort collectif, il est important de compter sur le feedback de votre équipe pour identifier les améliorations à apporter. Les story points agile ne sont peut-être pas aussi intuitifs qu’une simple estimation du temps nécessaire, mais vous constaterez qu’en vous focalisant sur les efforts plutôt que la durée, vos sprints seront plus calmes, votre équipe plus organisée et mieux préparée, et votre expérience globale beaucoup plus agréable. De plus, vous pourrez aborder les attentes avec les parties prenantes et fixer des dates de livraison plus raisonnables pour la suite, ce qui renforcera à la fois votre efficacité et la qualité du produit.