La pratique
« Pour moi, ça, c'est un 8 ! » « Jamais de la vie, c'est un 3 ! » Qui n'a jamais entendu cet échange en séance d'estimation ? Les deux ont peut-être raison, chacun avec sa propre échelle : les story points sont relatifs, et un 3 n'a de sens que comparé à autre chose. Encore faut-il que cette autre chose soit la même pour tout le monde.
Le référentiel d'estimation la rend visible. Pour chaque valeur de l'échelle, l'équipe tient une carte de référence : une méta-description de ce qu'une user story de cette taille doit être, et un ou plusieurs exemples réels, des user stories qu'elle a elle-même terminées. La question n'est plus « combien vaut cette story ? », mais « à laquelle de nos cartes ressemble-t-elle le plus ? »
Le référentiel ne contient que des user stories terminées par l'équipe, au moins une par carte. Une story qu'elle a réalisée, l'équipe sait ce qu'elle lui a vraiment demandé ; une story imaginée, ou empruntée à une autre équipe, ne dit rien de son échelle.
Pourquoi une échelle commune
Les estimations servent d'abord la prédictibilité : savoir quelle quantité de travail sera terminée, et pour quand. Elles aident aussi à réduire les risques et la part d'incertitude, à décider et à prioriser, à établir la confiance et à aligner l'équipe. Aucun de ces usages ne tient si chacun lit l'échelle à sa façon : une vélocité faite de 3 qui ne pèsent pas la même chose d'un sprint à l'autre ne prédit rien.
Ce que mesure un point
Un point d'effort ne mesure pas seulement la complexité. Il rassemble tout ce que l'équipe met derrière une user story :
- L'effort : le travail à fournir pour aller au bout de la story.
- La complexité : la difficulté qu'elle peut comporter.
- Les risques : ce que l'on imagine pouvoir rencontrer pendant le développement.
- Les inconnues : ce que l'on ignore encore au moment d'estimer.
- Les dépendances : les éléments extérieurs dont la story a besoin.
L'effort reste lié, indirectement, au temps que l'équipe passera sur la story : dire que le temps n'a rien à voir avec l'estimation n'est pas tout à fait vrai. Mais on ne convertit pas les points en jours : un 5, c'est « plus gros que ce 3-là, plus petit que ce 8-là ». Une carte de référence porte toutes ces dimensions à la fois, dans un exemple que chacun a vécu.
Bien définir la plage
L'échelle la plus courante reprend la suite de Fibonacci, où chaque nombre est la somme des deux précédents : 1, 2, 3, 5, 8, 13. Les écarts se creusent à mesure qu'elle grandit, et c'est voulu : plus l'estimation est haute, plus elle est imprécise. Distinguer 12, 13 ou 14 n'aurait guère de sens ; 13 représente tout cet intervalle.
Beaucoup d'équipes s'arrêtent à 13, mais il n'y a pas de règle : le jeu du Planning Poker, lui, prolonge la suite par 20, 40 et 100. L'important est que l'équipe se mette d'accord, avant de construire ses cartes, sur la plage qu'elle utilise et sur ce qui se passe au-delà, par exemple : au-dessus de 13, on découpe.
Construire les cartes
- On choisit les exemples. L'équipe reprend les user stories terminées lors des derniers sprints, celles dont elle se souvient bien. Pour chaque valeur de la plage, elle en retient au moins une qui lui paraît représentative, plusieurs si elles éclairent la valeur sous des angles différents.
- On écrit la méta-description. En quelques mots, ce qu'une story de cette taille doit être : son effort, sa complexité, ses risques, ses inconnues, ses dépendances. Le format dépend de l'équipe ; l'essentiel est que chacun s'y reconnaisse.
- On rassemble les cartes. Une carte par valeur, avec sa valeur en points, sa méta-description et ses exemples. Le référentiel, ce sont ces cartes, sous la main à chaque séance d'estimation.
| Carte | Ce qu'une story de cette taille doit être |
|---|---|
| 1 | Une modification minime et bien connue : un libellé, un paramètre, sans nouvelle règle. |
| 2 | Une petite évolution d'un élément existant, sans risque identifié. |
| 3 | Une évolution bien comprise, qui touche un seul composant, sans dépendance extérieure. |
| 5 | Une fonctionnalité nouvelle dans un périmètre connu, avec quelques règles à tester. |
| 8 | Une fonctionnalité qui touche plusieurs composants, ou qui comporte une inconnue à lever. |
| 13 | Plusieurs composants, une dépendance extérieure ou une forte incertitude : à la limite du découpage. |
Sous chaque description, la carte cite ses exemples réels : ce sont eux, plus que les mots, qui donnent au chiffre un sens concret.
En séance
Le référentiel ne remplace pas la séance d'estimation : on estime comme d'habitude. Il sert de rappel en cas d'hésitation ou de divergence. Quand l'écart est trop grand, on ressort les cartes et on rappelle ce qu'est un 3, ou un 5, pour l'équipe, exemples à l'appui. Le 8 et le 3 de tout à l'heure se comparent alors à la même story, et la discussion porte enfin sur l'élément à estimer, plus sur l'échelle.
Le faire vivre
Le référentiel appartient à l'équipe : c'est elle qui le met à jour, régulièrement, ou quand elle estime qu'il a trop évolué, quand une carte ne correspond plus à ce qu'elle entend aujourd'hui par un 3 ou un 5. Les stories terminées depuis la dernière mise à jour fournissent de nouveaux exemples ; une story de référence que plus personne ne reconnaît laisse sa place.
Quand l'utiliser
Dès que l'équipe a terminé quelques sprints ensemble : il faut des stories terminées pour remplir les cartes. Ensuite, le référentiel sert à chaque séance d'estimation, et d'autant plus que les écarts se répètent.
Il convient
- Estimations qui divergent souvent, sans que personne ne sache dire pourquoi
- Équipe qui a déjà terminé quelques sprints ensemble
- Nouvel équipier qui doit apprendre l'échelle de l'équipe
- Vélocité ou coefficient de focalisation utilisés pour prévoir : ils supposent une échelle stable
Mieux vaut l'éviter
- Équipe qui n'a encore rien terminé ensemble : une référence connue de tous suffit pour commencer
- Pour aligner les points de plusieurs équipes
- Pour convertir des points en jours
- Travail en flux continu, sans estimation
Une séance d'eXtreme Quotation laisse sur la table des stories de chaque taille, classées par toute l'équipe. Une fois terminées, elles font un excellent point de départ pour les cartes du référentiel.
Retour d'expérience terrain
Le point de départ
J'ai introduit le référentiel lors d'un atelier sur l'estimation. Avant de construire quoi que ce soit, nous avons repris les bases ensemble : pourquoi estimer, ce que recouvre un point d'effort, pourquoi la suite de Fibonacci. Le référentiel venait en dernier, comme l'aboutissement : une fois d'accord sur ce que l'on mesure, il restait à se donner des repères communs.
Ce qui a changé
Rapidement, les estimations sont devenues plus constantes. Le découpage nécessaire se fait plus naturellement : une story qui ne ressemble à aucune carte, ou qui dépasse la plus grosse, se repère tout de suite. Et la qualité des user stories s'est elle aussi améliorée.
Ce que je retiens
Bien définir la plage à utiliser, dès le départ. L'équipe doit se mettre d'accord, par exemple, qu'au-dessus de 13, on découpe. Une fois la règle posée, une story trop grosse n'est plus un débat sur sa taille : c'est une story à découper.
Limites à garder en tête
- Un référentiel par équipe. Les cartes d'une équipe ne valent que pour elle : ne les imposez pas à une autre, et ne comparez pas les points de deux équipes.
- Il vieillit. L'équipe gagne en connaissance, son code et ses outils changent : une carte qu'on ne revoit jamais finit par décrire une autre équipe.
- Une carte n'est pas une case. On compare pour se mettre d'accord, pas pour faire entrer chaque story de force dans une valeur ; une story qui ne ressemble à aucune carte mérite une discussion.
- Il ne rend pas une story prête. Une story floue reste floue, même bien comparée : le référentiel aide à repérer ce qu'il faut découper ou clarifier, il ne le fait pas à la place de l'équipe.
Pour aller plus loin : Mike Cohn, « Story Points Estimate Effort Not Just Complexity », sur ce que recouvre un point (en anglais).