Comment estimer une User Story ? Les différentes méthodes !

Il y a une règle à appliquer à toutes épreuves dans le développement d’un produit avec la méthode Agile.

Toutes les User Stories du Backlog doivent être estimées avant d’être intégrées dans un sprint.

Mais comment estimer une User Story ? 

Dans cet article, nous verrons comment estimer une User Story avec les différentes méthodes existantes ainsi que les étapes à suivre.

Pourquoi faut-il estimer nos User Stories ?

C’est l’estimation des User Stories qui va permettre à l’équipe de déterminer celles qui peuvent être traitées dans le prochain sprint et celles qui restent dans le backlog. 

Voici, les principaux bénéfices qu’apporte une bonne estimation : 

• L’estimation d’une US nous permet de voir si elle est trop grosse et si elle a besoin d’être redécoupée : En effet, une US doit être réalisable par un membre de l’équipe dans le temps défini du sprint. Si ce critère n’est pas respecté, cela signifie que la tâche demandée est trop conséquente et qu’elle doit être découpée plus finement. 
• Elle favorise une compréhension globale du travail demandé : Pour estimer une US, l’équipe a besoin d’en savoir le plus possible sur la fonctionnalité en question. À la suite du Sprint Planning, toute l’équipe doit être sur la même longueur d’onde. 
• Elle permet de définir l’engagement et calculer la vélocité d’une équipe : La somme des estimations des US qui sont intégrées dans un Sprint représente l’engagement que se donne l’équipe. Cet objectif doit être atteint à la fin de l’itération.
• Estimer les différentes US dans un backlog apporte une aide cruciale au travail de priorisation : Une estimation va définir l’effort nécessaire pour réaliser la tâche. 

Le choix de l’intégration d’une US dans un sprint se repose sur l’estimation de l’équipe ainsi que la valeur qu’apporte l’US au produit final. 

Si l’US a une estimation élevée et une valeur faible pour le produit, elle ne sera pas considérée comme prioritaire.

Chaque US prend une certaine place plus ou moins importante dans le sprint selon leur estimation. 
Plus les US représentent un effort important, plus elles ont des estimations hautes, plus elles remplissent vite l’engagement de l’équipe et moins on peut intégrer d’US dans le prochain Sprint. 

Quelles sont les étapes à suivre pour estimer une User story ?

Comment estimer une User Story : Le processus 

Avant de se lancer, il faut bien entendu avoir, auparavant, créer un backlog, rédigé ses User Stories et préparer la cérémonie du Sprint Planning.

Mais il faut aussi clarifier quelques détails. 

La notion de Story points dans un projet Agile

Les Story Points sont utilisés dans la gestion et le développement d’un produit agile pour estimer la difficulté de mise en œuvre d’une user story. 

Le point de complexité qui est donné à l’US va représenter l’effort requis pour la développer. 

En se référant à ce nombre, l’équipe de développement connaît la difficulté de réalisation d’une fonctionnalité.

La difficulté est calculée avec la complexité du développement, les risques pour le produit et les efforts engagés. 

La somme des Story Points des US qui sont intégrées dans un Sprint représente l’engagement de l’équipe et la somme des Story points de celles qui seront terminées à la fin de l’itération définit la vélocité d’une équipe. 

Estimer des US avec des Story Points Agiles est donc une notion essentielle du cadre méthodologique Scrum.

3 méthodes d’estimation d’une User Story

Toutes les US auront des Story Points, mais il existe plusieurs échelles pour estimer ses User Stories :

• La méthode d’estimation linéaire (1 ; 2 ; 3 ; 4 ; 5 ; 6 ; 7 ; 8 ; 9 ; 10 …)
• La séquence de Fibonacci (0,5 ; 1 ; 2 ; 3 ; 5 ; 8 ; 13 ; 20 ; 30 ; 50 ; 100 ; 200)

C’est la séquence de Fibonacci qui est la plus utilisée dans la méthode Scrum. 

C’est une échelle exponentielle qui permet de fournir moins de détails pour les US imposantes (3 ; 5 ; 8 ; 13 …) mais qui reste précise pour les US de petites tailles (0,5 ; 1 ; 2 ; 3).  

Une méthode d’estimation linéaire rend généralement le Sprint Planning plus long et laborieux. 

À force de chercher la précision, à pousser une équipe à choisir entre 8 ou 9 story points, les US estimées ne seront plus aussi fiables.  

Il y a trois méthodes principales pour donner à l’US ses Story Points Agiles : 

• La méthode du Planning Poker qui s’utilise si vous avez choisi la séquence de Fibonacci comme échelle ;
• La méthode du Bucket System qui peut s’utiliser avec les deux échelles de Story Points ;
• Idem pour la méthode de taille de T-shirt 

Estimer les Story Points avec le Planning Poker 

Ce jeu est composé d’un certain nombre de lots de cartes représentant chacun la séquence de Fibonacci.

Il y a aussi des cartes avec le symbole de l’infini, une carte “?”  et généralement une carte “Pause Café”.

Les valeurs faibles correspondent aux US les plus simples et les valeurs de 5 à 13 sont plutôt utilisées pour les tâches plus complexes. 

Les cartes 100, 200 sont utilisées si une US est beaucoup trop complexe et doit être redécoupée par le PO. 

La carte “infini” s’utilise si une US doit être redécoupée est répartie sur plusieurs Sprint pour être réalisée. 

La carte “?” est généralement utilisée quand l’US n’est pas assez clairement rédigée ou si l’équipe se pose trop de question . Elle ne pourra alors pas l’estimer. 

Une fois que l’équipe s’accorde sur une carte, le nombre de story points est retranscrit sur l’US.

2) Estimer les Story Points avec le Bucket System 

Cela reste similaire au Planning Poker cependant, au lieu d’avoir des cartes, les membres de l’équipe utilisent des seaux.

Chaque contenant est matérialisé par des post-its ou n’importe quel autre support avec leur valeur.

On peut utiliser la suite de Fibonacci ou une séquence de chiffre linéaire.

Les membres de l’équipe vont choisir de mettre les US dans les différents seaux qui représentent leur complexité. 

A la fin de l’estimation, les valeurs des contenants sont reportées sur les US qu’ils contiennent.

3) Estimer les Story Points avec la taille de T-shirt

Cette méthode est un peu moins précise que les autres, mais très utile s'il y a un grand nombre d’US à estimer rapidement ou si l’équipe a eu des difficultés à s’accorder sur des valeurs lors des Sprint plannings précédents. 

Chaque fonctionnalité est discutée entre les participants pour savoir dans quelle catégorie elle se place : XS, S, M, L, XL. 

Les catégories XS, S représentent les tâches simples à réaliser et les catégories L, XL les US plus complexes ou celles à découper.

XS va donc représenter 1 Story Point, S = 2, M = 5, L = 13 et XL = 100.

Même si c’est mon devoir de vous présenter toutes les méthodes, je vous conseille d’utiliser comme échelle la séquence de Fibonacci et la méthode du Planning Poker.

Mes astuces pour estimer des User Stories de manière efficace 

Donner des points de complexités aux US peut s’avérer long et laborieux. Voici quelques astuces pour que vos Sprint Plannings respectent le timing.

Ordonnez vos US de la plus petite à la plus grande

Il est plus facile d’estimer des US qui sont déjà classées par taille. 

Pour les ordonner, prenez deux US et décidez laquelle est la plus complexe. Placez la plus compliquée en dessous de l’autre. 

Ensuite, prenez une autre des US du backlog et mesurez-la aux deux autres :

• Si elle est moins complexe que la première, placer là au-dessus.
• Si elle est plus complexe que la première, mais moins complexe que la deuxième, placez-la au milieu.
• Si elle est moins complexe que les deux US déjà classés, placez là en première, au-dessus des autres.

Faîtes de même avec toutes les autres US prévues pour le sprint suivant. 

Définissez des points de référence

Lorsque vous abordez un tout nouveau groupement d’US non estimées avec votre équipe, cela peut sembler intimidant. 

Tout d’abord, trouvez un élément de petite taille, mais pas le plus petit. Cette US sera votre référence pour 2 Story Points. 

Ensuite, trouvez une autre US qui est deux fois ou trois fois plus complexe que celle à 2 Story Points. Cette US sera votre référence pour 5 Story Points. 

Une fois que vous avez vos deux références, il est plus facile d’estimer les autres par rapport à celles-là.

Attention : N’utilisez pas la notion de temps de développement pour l’estimation de vos US 

Parfois, vous serez tenté d’utiliser le temps pour estimer des US afin de calculer précisément la date à laquelle une fonctionnalité pourra être livrée. 

Ne tombez pas dans ce piège. 

Il y a une raison pour laquelle cette méthode ne fonctionne plus. 

Chaque équipe produit travaille sur des fonctionnalités et des produits nouveaux. 

Il n’y a pratiquement pas de répétition de tâches ou de fonctionnalités déjà développées auparavant. 

Cela rend le calcul des heures nécessaire à la réalisation d’une tâche absolument impossible. 

Les heures ne sont plus le moyen d’estimation le plus précis parce que c’est trompeur, c’est trop détaillé et surtout incorrect.  

L’équipe de développement ne peut pas savoir combien d’heures précises, il faudra pour terminer une tâche lorsqu’il s’agit d’une tâche complexe ou nouvelle. 

Cela se traduira soit par une surestimation de la part de l’équipe de développement pour sécuriser leur engagement ou une frustration des parties prenantes s'il y a du retard.

En conclusion 

Maintenant que vous connaissez comment estimer une User Story, n’oubliez pas que l’estimation doit toujours être effectuée avec toute l’équipe, y compris les développeurs, le Scrum master et les testeurs. Collaborez, discutez et décidez.

Dites-moi en commentaire quelle méthode d’estimation, vous utilisez avec votre équipe ?