Exemples de points d’histoire : une échelle de référence de 1 à 13
Six exemples de backlog pour aider votre équipe à comparer le travail, questionner les hypothèses et choisir ses propres histoires de référence.
Une estimation en points d’histoire exprime la taille relative du travail pour une équipe, en tenant compte de l’effort, de la complexité et de l’incertitude. Cela fait d’un élément achevé et familier une référence utile pour discuter du suivant. Le guide d’estimation d’Atlassian explique cette approche relative.
Par exemple, une équipe peut attribuer 2 points à un changement de paramètres familier et 5 à un nouveau workflow de notification. La question utile est : quel travail supplémentaire explique cette différence ?
Les exemples ci-dessous appartiennent à une équipe fictive construisant un espace de travail de documents partagé. Ils sont des points de départ pour une discussion, pas des tarifs standards pour des fonctionnalités. Votre équipe peut raisonnablement choisir des valeurs différentes.
Six exemples sur l’échelle d’une équipe
Supposez que cette équipe dispose déjà d’une bibliothèque de composants, des permissions de l’espace de travail, d’un service de notification et de contrôles automatisés sur ses workflows existants. Chaque estimation inclut l’implémentation, la revue, et les vérifications nécessaires pour répondre à la définition de terminé de l’équipe.
| Points | Élément du backlog | Inclus dans cet exemple | Pourquoi cette équipe le place ici |
|---|---|---|---|
| 1 | Expliquer un fil d’activité vide | Texte validé et composant d’état vide existant ; aucun nouveau comportement | Un petit changement familier avec peu d’états affectés |
| 2 | Permettre aux admins de l’espace de travail de changer le nom affiché partagé | Formulaire de paramètres existant, API et vérification des permissions d’admin ; validation et états enregistrés/erreur | Un chemin familier avec quelques vérifications de comportements ; l’élément de référence de l’équipe |
| 3 | Filtrer les documents par leur propriétaire | Composant filtre existant et support API ; comportement de réinitialisation et résultats vides | Plus d’états d’UI interactifs que la référence, avec un chemin de données connu |
| 5 | Notifier un propriétaire de document lorsqu’une demande d’accès est faite | Service de livraison existant ; vérifications des permissions, contenu de notification, gestion des doublons et lien vers la demande | Plusieurs éléments existants doivent bien fonctionner ensemble |
| 8 | Transférer la propriété d’un document dans un espace de travail | Nouvelle opération de transfert ; changements de permissions, éditions concurrentes et entrée d’audit | Une transition d’état plus large avec des cas d’échec nécessitant une entente soigneuse |
| 13 | Déplacer un dossier et ses documents dans un autre espace de travail | Permissions de destination, liens, échecs partiels et gestion de récupération | Trop de décisions interdépendantes pour que cette équipe garde un seul élément confortable ; discuter d’une découpe |
Les hypothèses d'infrastructure sont importantes. Une équipe sans service de notification estimerait un travail supplémentaire dans l’exemple à 5 points. Une équipe disposant d'une opération de transfert de propriété éprouvée pourrait évaluer cet élément plus bas.
Ces chiffres ne sont pas une formule. Compter les écrans UI, les endpoints ou les critères d’acceptation ne reproduira pas les estimations de manière fiable.
Comment la portée modifie l’estimation
Considérez « changer un nom affiché d’espace de travail ». Le tableau suppose un admin modifiant l’étiquette partagée visible dans les paramètres, avec un endpoint de mise à jour et une vérification des permissions existants.
Modifiez maintenant les conditions d’acceptation :
| Version | Portée | Estimation indicative |
|---|---|---|
| A | Modifier l’étiquette affichée dans les paramètres de l’espace de travail ; utiliser l’opération de sauvegarde existante | 2 |
| B | Mettre aussi à jour le contenu des invitations et la navigation mise en cache ; garder ces surfaces cohérentes si une mise à jour réussit partiellement | 5 |
| C | Le nom détermine aussi l’URL publique de l’espace ; préserver les anciens liens et gérer les collisions | Pause pour clarifier, puis éventuellement 8 ou découper |
La version C soulève une question produit avant une question de taille : la modification du nom doit-elle changer l’URL ? Décider de conserver une URL stable pourrait supprimer beaucoup de travail supplémentaire.
Si un participant vote 2 et un autre 8, demandez à chacun de décrire le comportement inclus. Ils peuvent raisonner de manière cohérente sur des versions différentes. Réécrivez les conditions d’acceptation avant un nouveau vote.
Choisissez des histoires de référence que votre équipe connaît
Choisissez deux ou trois éléments terminés avec des limites claires. Un petit changement familier, un workflow modéré et un changement plus important mais compris offrent à l’équipe plus de comparaisons utiles qu’un seul nombre abstrait.
Pour chaque référence, gardez une brève note :
- Quel résultat utilisateur a-t-il livré ?
- Quels systèmes et états ont changé ?
- Quel travail de revue et de validation a été inclus ?
- Quelles hypothèses l’ont rendu simple ou complexe ?
Puis comparez le nouveau travail à la référence la plus proche. « Cela ressemble à notre changement de paramètres, mais ajoute deux chemins de permissions » donne aux personnes un élément concret à challenger.
Si l’équipe n’a pas d’historique de livraison partagé, choisissez un élément bien compris comme référence provisoire. Revoyez-le après livraison et gardez les hypothèses visibles. Il n’est pas nécessaire de fabriquer une échelle parfaite avant que l’équipe ait appris ensemble.
Copiez cette note d’estimation dans un élément du backlog
Utilisez ce qui suit comme aide à la discussion dans votre backlog ou notes d’équipe :
Résultat utilisateur :
Comportement inclus :
Explicite exclu :
Référence terminée la plus proche :
Ce qui rend ceci plus petit ou plus grand :
Incertitudes pouvant modifier la portée :
Décision : estimer / découper / investiguer
Estimation convenue, si prête :
Prochaine clarification et responsable, si nécessaire :
Voici un exemple rempli pour l’élément notification d’accès :
Résultat utilisateur : le propriétaire du document apprend qu’un membre de l’espace de travail a demandé l’accès et peut ouvrir la demande.
Inclus : utiliser le service de notification existant, vérifier les permissions du destinataire, lier à la demande en attente, et éviter les notifications en double lors de la nouvelle tentative de livraison.
Exclus : emails de rappel, digests quotidiens et attribution automatique d’accès.
Référence : notre changement de paramètres à 2 points utilise un chemin de sauvegarde familier. Cet élément combine les chemins de demande, permissions et livraison, impliquant plus de coordination et de cas d’échec.
Question ouverte : le service empêche-t-il déjà les livraisons en double ? Le mainteneur du service de notification confirmera avant que nous fixions l’estimation.
Dans ce scénario fictif, cette vérification confirme la prise en charge de la livraison réutilisable et l’équipe s’accorde sur 5. Sinon, l’équipe doit discuter du travail supplémentaire avant d’utiliser le même chiffre. La référence explique la comparaison ; elle ne calcule pas la réponse.
Pour la séquence de réunion, utilisez le guide Planning Poker pas à pas. Il couvre le vote privé, la discussion des différences, et le choix du résultat du tour suivant.
Quand un chiffre n’est pas encore utile
Retournez à la clarification lorsqu’une inconnue change la nature du travail. « Quel texte la notification doit-elle utiliser ? » est une incertitude différente de « L’espace de travail de destination autorise-t-il les utilisateurs externes ? »
Pour l’exemple de déplacement de dossier, l’équipe pourrait d’abord convenir d’un résultat utilisateur plus restreint : déplacer un document entre les espaces de travail que l’utilisateur administre. Cette première partie nécessite toujours des permissions de destination claires, des règles d’accès préservées et une gestion sécurisée des échecs pour éviter de perdre le document ou d’exposer le document au mauvais interlocuteur en cas d’interruption. Déplacer des lots de documents peut être un élément séparé. Réduire la taille du lot restreint le travail mais n’élimine pas la nécessité de gérer les échecs.
Après la découpe, estimez chaque élément individuellement. Les nouveaux chiffres ne doivent pas forcément revenir à 13 : l’équipe a modifié la portée et mieux compris le travail.
Questions fréquemment posées par les équipes
Combien d’heures représente une story à 3 points ?
Il n’existe pas de conversion universelle. Les exemples ici comparent le travail au sein d’une équipe fictive. Si vous avez besoin d’une prévision de livraison, utilisez votre propre historique de livraison et capacité actuelle, et discutez de l’incertitude séparément du label point.
Est-ce que chaque bug vaut 1 point ?
Non. Une erreur d’affichage reproductible avec une cause identifiée diffère d’une perte de données intermittente dont la cause est inconnue. Clarifiez ce que vous estimez : la correction, une investigation, ou les deux.
Chaque équipe doit-elle découper une story à 13 points ?
Non. Ici, 13 marque un travail que cette équipe souhaite examiner et découper. La limite dépend des références de votre équipe et de sa capacité à comprendre et livrer un élément.
Intégrez vos références dans Planning Poker
Choisissez quelques éléments à venir, rédigez leurs critères d’acceptation et conservez vos histoires de référence à leurs côtés. Utilisez Agilo Planning Poker pour la session d’estimation de l’équipe.
Créez une salle Planning Poker lorsque les éléments sont prêts à être discutés.
