Les story points en développement — ce qu'ils sont, les échelles d'évaluation et leur application
Les story points sont des unités relatives pour mesurer la complexité des tâches dans les méthodologies de développement agiles. Contrairement aux heures, les story points prennent en compte non seulement le temps, mais aussi la complexité, les risques et l'incertitude d'une tâche. Selon Scrum.org, 2023, les équipes qui utilisent l'estimation relative en story points manquent les délais de sprint 25% moins souvent que les équipes qui estiment en heures.
Points clés
- Story points — unités relatives de complexité de la tâche, non liées au temps.
- Échelles principales — Fibonacci (1, 2, 3, 5, 8, 13, 21) et linéaire (1, 2, 3, 4, 5).
- Velocity — le nombre de story points qu'une équipe termine par sprint, utilisé pour les prévisions.
- Principal avantage — les story points ne dépendent pas du développeur spécifique et reflètent la complexité pour l'équipe.
- Règle clé — une tâche de référence définit l'échelle : l'équipe se met d'accord sur ce que signifie 1 story point.
Qu'est-ce que les story points ?
Les story points sont une mesure de la complexité des tâches utilisée dans Scrum et d'autres méthodologies agiles. L'équipe évalue chaque tâche non pas en heures, mais en unités relatives : « cette tâche est deux fois plus complexe que la référence ». Cette approche nivelle la différence de vitesse entre les différents développeurs et se concentre sur la complexité.
Origine du terme
Le concept de story points est apparu au début des années 2000 avec la popularisation de Scrum. L'un des premiers à décrire la méthode fut Ron Jeffries dans le cadre de l'Extreme Programming (XP). L'idée était de s'éloigner de l'estimation en « heures-homme », toujours imprécise, pour se tourner vers une complexité relative que l'équipe détermine collectivement. Aujourd'hui, les story points sont la norme de l'industrie pour les équipes agiles.
Facteurs pris en compte dans les story points
Lors de l'estimation en story points, l'équipe prend en compte trois facteurs : le volume de travail (quantité de code, d'écrans, de logique), la complexité (défis techniques, nouvelles technologies) et l'incertitude (exigences peu claires, risques). Un story point peut signifier « une tâche simple sans risques », tandis que 8 peut signifier « une tâche complexe avec une forte incertitude ».
Échelles de story points : comment choisir
Le choix de l'échelle de story points affecte la précision de l'estimation et la commodité de la planification. L'échelle la plus populaire est la séquence de Fibonacci, mais il existe des alternatives.
| Échelle | Valeurs | Avantages | Inconvénients |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Augmentation naturelle de l'écart pour les grandes tâches | Difficile pour les nouvelles équipes |
| Linéaire | 1, 2, 3, 4, 5 | Simple et compréhensible | Pas d'écart pour les grandes tâches |
| Puissance | 1, 2, 4, 8, 16, 32 | Écart maximal pour les grandes tâches | Difficile de distinguer les grandes tâches |
| Taille de T-shirt | S, M, L, XL | Estimation rapide et approximative | Imprécise, nécessite une conversion |
Pourquoi Fibonacci ? La psychologie de l'échelle
La séquence de Fibonacci n'a pas été choisie par hasard. La différence entre 1 et 2 est minime (50%), tandis qu'entre 13 et 21 elle est significative (62%). Cela reflète la réalité : les petites tâches sont estimées plus précisément, les grandes tâches avec un plus grand écart. Lorsqu'une tâche est estimée à 21 story points, l'équipe comprend : « nous ne savons pas combien de temps cela prendra, mais c'est définitivement plus que 13 ». L'échelle de Fibonacci évite la fausse précision.
La tâche de référence — base de l'échelle
Pour que l'échelle fonctionne, l'équipe se met d'accord sur une référence : « la tâche X est 1 story point ». Généralement, une tâche simple et bien connue est choisie comme référence : « ajouter un champ de texte à un écran » ou « corriger une faute de frappe ». Toutes les autres tâches sont estimées par rapport à la référence. Sans référence, les story points perdent leur sens — chacun comprend l'unité différemment.
Velocity de l'équipe et prévisions
Velocity est le nombre moyen de story points qu'une équipe termine par sprint. C'est une mesure clé pour prévoir les délais du projet.
Comment la velocity est calculée
Velocity est calculée sur la base des tâches terminées : on additionne les story points de toutes les tâches que l'équipe a réussi à terminer (la définition de terminé est respectée). Les tâches non terminées ne sont pas comptées. Pour plus de précision, on prend la moyenne des 3 à 5 derniers sprints. Par exemple, si une équipe a terminé 20, 22, 18 et 24 story points au cours des 4 derniers sprints, velocity = 21 sp.
Prévisions via la velocity
Connaissant la velocity et le volume total du backlog en story points, vous pouvez prévoir le nombre de sprints jusqu'à la livraison. Par exemple, si le backlog contient 210 story points et que la velocity = 21, il faudra 10 sprints. Il s'agit d'une prévision approximative qui s'affine au fur et à mesure de l'avancement. Important : la velocity est une moyenne, pas un engagement. Planifiez sur la base de la limite inférieure (18 sp), pas de la moyenne.
Comment augmenter la velocity
Velocity ne peut pas être augmentée par décret — c'est un symptôme de la santé des processus. Une croissance durable de la velocity est obtenue grâce à : la réduction de la dette technique, l'amélioration des processus de revue de code, la réduction des changements de contexte, l'automatisation des tests et du CI/CD. Important : la velocity de différentes équipes ne peut pas être comparée — chaque équipe définit les story points à sa manière.
Story points vs heures : quoi et quand utiliser
Les story points et les heures ont des objectifs différents, et le choix entre eux dépend du contexte. Les équipes expérimentées utilisent les deux approches pour différentes tâches.
Quand les story points fonctionnent mieux
Les story points sont indispensables pour la planification des sprints : ils ne dépendent pas de la personne qui effectuera la tâche. Un junior peut faire 2 sp par jour, un senior 4 sp, mais l'estimation de la tâche reste de 2 sp pour les deux. Les story points permettent de suivre la productivité de l'équipe sans comparer les développeurs. Cela réduit la pression politique et améliore l'ambiance de l'équipe.
Quand les heures sont nécessaires
Les heures sont nécessaires pour les engagements externes : contrats, budgets, rapports clients. Un client veut savoir non pas « 8 story points » mais « 3 semaines ». Pour convertir les story points en heures, utilisez le taux de conversion historique : l'équipe sait que 1 sp équivaut à environ 4 heures de travail. La conversion doit être transparente et basée sur des données, pas sur des suppositions.
Approche combinée
De nombreuses équipes utilisent une approche combinée : les tâches sont estimées en story points pour la planification du sprint, puis le manager les convertit en heures/jours pour les rapports externes. Il est important de ne pas mélanger les deux systèmes dans un même processus : soit vous estimez en story points et dérivez le temps de la velocity, soit vous estimez directement en heures.
Erreurs courantes avec les story points
L'implémentation des story points est souvent accompagnée d'erreurs qui annulent les avantages de l'estimation relative. Voici les plus courantes.
Lier les story points au temps
L'erreur la plus courante — l'équipe convient : « 1 sp = 4 heures ». Dans ce cas, les story points perdent leur sens et se transforment en heures sous un autre nom. Les story points doivent être relatifs, non liés au temps. Si la tâche A est deux fois plus complexe que la tâche B, elle reçoit 2 sp, indépendamment du nombre d'heures qu'elle prendra.
Estimation post-factum
Lorsqu'une tâche est estimée après avoir été terminée — ce n'est pas une estimation, c'est une constatation. Les story points doivent être attribués avant le début du travail, au moment d'incertitude maximale. L'estimation post-factum fausse la velocity et n'apporte aucun bénéfice à la planification. De plus, elle crée un faux sentiment de précision.
Comparer la velocity entre équipes
Comparer la velocity de l'équipe A et de l'équipe B est un exercice sans signification. Chaque équipe définit la référence et l'échelle différemment. Pour une équipe, 1 sp est une tâche simple d'une heure, pour une autre, c'est une tâche d'une journée. Vous ne pouvez comparer que la velocity d'une même équipe dans le temps : si elle augmente ou diminue.
Échelle incohérente
Lorsque des tâches différentes avec la même complexité reçoivent des story points différents, et que les plus complexes en reçoivent moins, l'échelle se brise. L'équipe doit calibrer régulièrement l'échelle : tous les 3 à 6 sprints, examiner rétrospectivement dans quelle mesure les estimations correspondent à la complexité réelle. Cela améliore la cohérence des estimations.
Questions fréquentes
Combien d'heures y a-t-il dans un story point ?
Les story points n'ont pas d'équivalent fixe en heures. C'est une unité relative : 1 sp = complexité de la tâche de référence. Pour la conversion en heures, utilisez le taux de conversion historique de votre équipe : divisez le nombre moyen d'heures travaillées par sprint par la velocity. Généralement, 1 sp = 4 à 8 heures, mais cela varie pour chaque équipe.
Peut-on utiliser les story points dans Kanban ?
Oui, les story points peuvent être utilisés dans Kanban, mais avec des réserves. Kanban n'a pas de sprints fixes, donc la velocity est calculée par semaine ou par mois à la place. Les équipes Kanban utilisent souvent le Cycle Time au lieu des story points — le temps qu'une tâche prend du début à la fin. Le choix dépend des spécificités de l'équipe.
Que faire si l'équipe ne parvient pas à se mettre d'accord sur une estimation ?
Si les estimations divergent (l'un donne 3 sp, l'autre donne 13), c'est le signe que la tâche est mal comprise. Décomposez la tâche en parties plus petites. Discutez des risques et des incertitudes que les différents développeurs perçoivent. Si la tâche est grande, estimez-la comme un Spike (recherche de 2 à 4 jours) au lieu de story points.
Comment arrêter d'estimer en heures et passer aux story points ?
La transition prend de 3 à 6 sprints. Commencez par choisir une échelle (Fibonacci est le choix le plus sûr) et définir une tâche de référence. Organisez 2 à 3 sessions de Planning Poker. Calculez la velocity après chaque sprint. Ne convertissez pas les story points en heures — laissez l'équipe s'habituer au nouveau système. Après 3 sprints, vous verrez à quel point la planification s'est améliorée.
L'estimation en story points d'une tâche change-t-elle après son achèvement ?
Non, l'estimation ne change pas. Les story points sont une estimation préliminaire de la complexité faite avant le début du travail. Après l'achèvement de la tâche, l'estimation reste la même, même si l'effort réel était différent. Modifier l'estimation post-factum fausse les statistiques et annule le but de la prévision. Analysez les écarts lors des rétrospectives, mais ne modifiez pas les estimations rétroactivement.
Résumé
- Story points — unités relatives de complexité, non liées au temps, la base de l'estimation agile.
- Échelles principales — Fibonacci (recommandée), linéaire, puissance, taille de T-shirt.
- Velocity — nombre de story points par sprint ; mesure clé pour la prévision des délais.
- Story points vs heures — story points pour la planification des sprints, heures pour les engagements externes.
- Erreurs courantes — lien avec le temps, estimation post-factum, comparaison d'équipes, échelle incohérente.
- Tâche de référence — base de l'échelle ; sans elle, les story points perdent leur sens.
- Avantage clé — les story points ne dépendent pas de l'individu et permettent de se concentrer sur la productivité de l'équipe.
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi