L'éternel débat des équipes agiles. Spoiler : ce ne sont pas les mêmes choses, et les confondre coûte cher.
Le choix de l'unité précède celui des techniques d'estimation agile pour le sprint planning, et il conditionne chaque session de Planning Poker qui suit. Voici ce que mesure chaque unité, pourquoi « un point = quatre heures » ne tient pas, et comment répondre au manager ou au client qui a besoin de dates et de budgets.
Quelle différence entre story points et jours-homme ?
Story points et jours-homme ne répondent pas à la même question. Le jour-homme est une unité de temps : une personne qui travaille pendant une journée. Une estimation en jours-homme prédit la durée du travail pour une personne ou une équipe donnée. Le story point est une unité relative d'effort : il compare un élément du backlog à des stories de référence déjà connues de l'équipe et combine volume, complexité et incertitude, sans annoncer de durée. La différence essentielle : une estimation en jours-homme dépend de qui fait le travail, une estimation en story points non. Mike Cohn montre qu'un point peut représenter 2 heures pour un développeur expérimenté et 8 pour un junior : on ne convertit donc pas les points en heures avec un taux fixe. Les équipes qui doivent fournir des dates ou des budgets convertissent au niveau de l'équipe, grâce à la vélocité : les points terminés par sprint, mesurés sur plusieurs sprints, transforment un backlog en nombre de sprints, puis en calendrier et en coût.
Story points ou jours-homme : qu'est-ce qui change ?
| Critère | Story points | Jours-homme |
|---|---|---|
| Ce qu'on mesure | Effort relatif : volume, complexité, incertitude | Temps passé par une personne |
| Dépend de qui réalise | Non : l'équipe s'accorde sur une seule valeur | Oui : un senior et un junior donnent des chiffres différents |
| Stabilité dans le temps | Stable : un 5 reste un 5 quand l'équipe progresse, c'est la vélocité qui augmente | Se périme : à refaire quand les compétences, l'équipe ou le contexte changent |
| Reflète l'incertitude | Oui, par les écarts croissants de l'échelle | Rarement : un chiffre unique masque le risque |
| Usage en planification | Vélocité de l'équipe et prévision de release | Staffing, budget, contrats et facturation |
La ligne « stabilité » est la moins évidente et la plus utile. Dans Agile Estimating and Planning, où il compare story points et jours idéaux, Mike Cohn souligne que les estimations en story points ne se périment pas : quand l'équipe va plus vite, les stories gardent leur taille et c'est la vélocité qui monte. Une estimation en jours-homme faite il y a un an, avant que l'équipe ne maîtrise le code, est tout simplement fausse.
Pourquoi les équipes agiles ont-elles arrêté d'estimer en jours ?
Elles ont commencé par là. Dans Story Points Revisited, Ron Jeffries raconte que les premières équipes Extreme Programming estimaient en « jours idéaux », multipliés ensuite par un facteur de charge, souvent autour de trois, pour obtenir le temps réel. Les parties prenantes ne comprenaient pas qu'une tâche d'un jour en prenne trois : l'équipe a renommé l'unité en « points ».
La comparaison de Cohn explique pourquoi ce choix a tenu. Les jours idéaux sont plus faciles à expliquer hors de l'équipe et plus faciles à estimer au début, mais les jours idéaux de l'un ne s'additionnent pas avec ceux de l'autre. Les story points, si : toute l'équipe s'accorde sur une seule valeur par story.
Le jour-homme a un autre effet pervers : il rend les personnes interchangeables. Si un développeur met trois jours, deux devraient en mettre un et demi. Fred Brooks y a répondu dès 1975 dans The Mythical Man-Month, avec ce qu'on appelle la loi de Brooks : ajouter des personnes à un projet logiciel en retard le retarde encore davantage.
Pourquoi un taux de conversion fixe ne fonctionne-t-il pas ?
Dans Don't Equate Story Points to Hours, Mike Cohn prend une équipe de deux personnes. Superstar est quatre fois plus productif que Junior. Sur un sprint de 40 heures, l'équipe livre 25 points : 20 pour Superstar, 5 pour Junior. Pour Superstar, un point vaut 2 heures. Pour Junior, 8 heures. Pour l'équipe, 3,2 heures.
Aucun de ces chiffres n'est « le » taux de conversion. Pour Cohn, le lien entre points et heures est une distribution : les stories à 1 point se regroupent autour d'une certaine durée, celles à 2 points autour du double environ, avec des chevauchements entre valeurs voisines. Figer « 1 point = 4 heures » ramène tout ce que les points devaient éviter : l'estimation dépend de nouveau de qui prendra la story, et un chiffre d'apparence précise cache une large fourchette.
Comment passer des story points aux jours, alors ?
On convertit au niveau de l'équipe et du sprint, jamais story par story.
- Mesurer la vélocité sur au moins trois sprints, en gardant une fourchette (la plus basse et la plus haute) plutôt qu'une moyenne unique.
- Estimer le reste du backlog en story points, par exemple lors d'une session de Planning Poker.
- Diviser le backlog par chaque borne de la fourchette de vélocité pour obtenir un nombre de sprints.
- Traduire les sprints en calendrier et en jours-homme avec la capacité de l'équipe : nombre de personnes × jours ouvrés par sprint.
Un exemple, avec des chiffres fictifs : cinq développeurs, des sprints de deux semaines (10 jours ouvrés), une vélocité entre 20 et 25 points et une release de 120 points. On obtient 120 ÷ 25 = 4,8, soit cinq sprints dans le meilleur cas, et 120 ÷ 20 = 6 sprints dans le pire : 10 à 12 semaines. Chaque sprint mobilise 5 × 10 = 50 jours-homme, la release coûte donc 250 à 300 jours-homme. Présentez-la comme une fourchette.
Pour le budget, Cohn applique la même logique à l'argent : diviser ce que coûte l'équipe sur une période par les points livrés sur cette période donne un coût par point. Ron Jeffries ajoute une mise en garde utile face aux parties prenantes : prédire des dates à partir des points reste, selon lui, une idée fragile. Il préfère des stories découpées très fin et des échéances de release proches. Notre guide du sprint planning montre comment la vélocité nourrit chaque sprint.
Quand les jours-homme restent-ils la bonne unité ?
Les jours-homme restent le bon outil quand la question porte vraiment sur le temps ou l'argent :
- Contrats au forfait et devis, très courants en ESN : le client achète un budget, pas une vélocité.
- Régie et TJM (taux journalier moyen), où la facturation se fait au jour travaillé, quelle que soit l'unité d'estimation de l'équipe.
- Staffing et capacité : congés, temps partiels, arrivée d'un nouveau membre.
- Tâches à l'intérieur d'un sprint, si l'équipe découpe ses stories. Mountain Goat Software recommande le Planning Poker pour les éléments du backlog, pas pour ces tâches.
Le bon réflexe : garder les story points au sein de l'équipe et traduire à la frontière, avec la vélocité et la capacité, plutôt que de demander aux développeurs d'estimer en jours.
Questions fréquentes
Combien d'heures vaut un story point ? Un story point ne correspond à aucun nombre d'heures fixe. Dans l'exemple de Mike Cohn, un point représente 2 heures pour un développeur, 8 heures pour un autre et 3,2 heures en moyenne pour l'équipe. Le lien entre points et heures est une distribution : on convertit via la vélocité sur un sprint, jamais story par story.
Peut-on convertir des story points en jours-homme pour un devis ? Oui, au niveau de l'équipe. On mesure la vélocité sur plusieurs sprints, on divise le backlog par la fourchette de vélocité pour obtenir un nombre de sprints, puis on multiplie par la capacité de l'équipe en jours-homme par sprint. On obtient une fourchette de jours-homme pour toute la release, pas un taux appliqué à chaque story.
Quelle différence entre jour idéal et jour-homme ? Un jour idéal est une journée de travail sans interruption sur une seule story, avec tout le nécessaire sous la main. Un jour-homme est une vraie journée calendaire d'une personne, réunions et imprévus compris. Les premières équipes Extreme Programming multipliaient les jours idéaux par un facteur d'environ trois, avant de les rebaptiser story points.
Faut-il estimer les stories en points et les tâches en heures ? Beaucoup d'équipes Scrum le font. Les story points dimensionnent les éléments du backlog pour la vélocité et la planification des releases, tandis que les heures ou les jours aident à découper une story en tâches pendant le sprint planning. Mountain Goat Software réserve d'ailleurs le Planning Poker aux éléments du backlog, pas aux tâches du sprint.
Sources
- Mike Cohn, Don't Equate Story Points to Hours, Mountain Goat Software
- Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005
- Mountain Goat Software, Planning Poker
- Ron Jeffries, Story Points Revisited, 2019
- Fred Brooks, The Mythical Man-Month, Addison-Wesley, 1975
Le concept est encore flou ? Commencez par ce qu'est un story point, puis voyez comment estimer un ticket agile.
Estimez en story points, pas en jours
Prêt à dimensionner votre backlog en effort relatif ? Créez une session Planning Poker gratuite, partagez le lien et laissez votre équipe voter en même temps. Sans inscription. Découvrez toutes les fonctionnalités, dont l'export CSV et PDF de vos estimations.
