J’ai entendu beaucoup d’explications différentes de ce que l’Histoire des Points de la moyenne et de la façon dont vous devriez utiliser. Presque toutes les équipes Scrum les utilisent, mais elles ne font pas partie du Guide officiel Scrum. Cet article vise à supprimer certains des points de L’histoire entourant le mystère., Je partagerai également les idées fausses les plus courantes que j’ai rencontrées.
Ce n’Points d’Histoire représenter?
Les Story points représentent l’effort requis pour mettre en ligne un PBI (Product Backlog Item). Chaque point D’histoire représente une distribution normale du temps. Par exemple, 1 point D’histoire pourrait représenter une plage de 4 à 12 heures, 2 points d’Histoire de 10 à 20 heures, etc., Cette distribution temporelle est inconnue lors de l’estimation. En utilisant des PBI de référence par rapport à laquelle estimer, il n’est pas nécessaire de savoir combien de temps cela prend. Vous voulez juste avoir une indication approximative du temps que le PBI prendra pour terminer.
Quels sont les avantages de l’utilisation de Points d’Histoire?
Les Story Points permettent à une équipe de:
- estimer rapidement les problèmes. L’Estimation est relative aux éléments de L’arriéré de produits déjà terminés. C’est plus rapide que l’estimation sans aucune référence.
- estimer sans donner un engagement de temps spécifique., Lors de l’estimation en heures, vous faites un engagement de temps précis. L’estimation en points D’histoire empêche de donner un engagement exact. Personne ne sait exactement combien d’heures vous nommez à un problème spécifique.
- Embrasser l’incertitude qui vient avec l’estimation. Les points d’histoire spécifient une plage de temps inconnue. La sélection à partir d’une séquence spécifique de points D’Histoire de type Fibonacci nous permet de capturer l’incertitude.
- suffisamment précis pour planifier les Sprints à venir. Cela nous permet de mieux gérer les attentes de temps des parties prenantes pour les travaux futurs.,
12 erreurs courantes commises lors de l’utilisation de Story Points
- assimilant les Story Points à de la complexité, de l’incertitude ou de la valeur
certains PBI peuvent être complexes et ne nécessitent pas beaucoup de temps. Un PBI implique la mise en œuvre d’un algorithme sophistiqué. L’équipe l’a déjà fait auparavant, elle pourra donc le faire rapidement. Le contraire peut aussi être vrai, un PBI simple qui prend beaucoup de temps. L’équipe doit refactoriser un petit morceau de code, affectant beaucoup de fonctionnalités. En conséquence, beaucoup de fonctionnalités doivent être testées en régression, ce qui prendra beaucoup de temps.,
L’incertitude dans l’estimation est capturée dans la séquence de Fibonacci de type Story point elle-même: 1, 2, 3, 5, 8, 13, 20, 40, 100. Le choix d’un nombre spécifique à partir de cette séquence reflète la quantité d’incertitude. Bien sûr, si l’incertitude est trop grande pour devis, vous pouvez utiliser le ‘?’ carte.
Les Story Points ne disent rien sur la valeur d’un PBI. Les points d’histoire fournissent une estimation approximative. Il se peut que cet article soit extrêmement précieux ou qu’il n’ajoute aucune valeur. Les Story Points aident à déterminer le ROI d’un PBI., Vous pouvez utiliser des Story Points pour prendre en compte l’effort pour fournir cette fonctionnalité avec la valeur. Mais comme la valeur est également incertaine, ne vous comptez pas encore riche.
Les points D’histoire concernent l’effort. La complexité, l’incertitude et le risque sont des facteurs qui influencent l’effort, mais chacun d’eux ne suffit pas à déterminer l’effort.
2. Traduire les points de L’histoire en heures
en traduisant les points de l’histoire en heures, vous cessez de bénéficier de la rapidité de l’estimation relative. Vous commencez à travailler en heures et risquez de donner un engagement., Il fournit un faux sentiment de précision que vous réduisez un point de l’histoire avec une plage de temps de 10-20 heures à un nombre précis comme 15 heures. Il sera plus difficile de parvenir à un accord dans les estimations lorsque vous travaillez dans le domaine exact des heures.
3. Calcul de la moyenne des Points D’histoire
dans une session de poker de planification, la moitié de l’équipe estime un PBI à 3 points D’histoire et l’autre moitié à 5 points D’histoire. Il est facile de résoudre la discussion en mettant simplement 4 points D’histoire comme estimation. L’équipe ne devrait pas le faire car elle tente une fois de plus de fournir un faux sentiment d’exactitude., Le point est de ne pas être précis à 100%. Le point est d’être assez précis pour planifier à l’avance. De plus, vous risquez de perdre une discussion précieuse en faisant la moyenne. Peut-être que 5 points D’histoire était une meilleure estimation.
4. Ajustement des estimations de points D’histoire des problèmes pendant le Sprint
lorsque l’équipe commence à travailler sur un problème, l’équipe ne doit pas ajuster l’estimation de points D’histoire. Même s’il s’avère que cette estimation était inexacte. Si l’estimation était inexacte, elle fait partie de la vitesse finale du Sprint. Il est normal que les estimations soient parfois désactivées., Vous ne perdrez pas cette information, et elle fera partie de la vitesse historique d’une équipe.
5. Jamais de bugs de pointage D’histoire
un bug sans rapport avec le Sprint actuel devrait simplement être pointé d’histoire. Le bogue représente le travail que l’équipe doit effectuer. Cela ne s’applique pas si l’équipe réserve un pourcentage fixe de temps pour travailler sur les bogues pendant le sprint. Un bogue lié à un problème dans le sprint ne doit pas être signalé car cela fait partie de l’estimation d’origine.
6. Ajouter des Points D’histoire à de petites tâches
Un petit pic pour enquêter sur quelque chose devrait juste être encadré., Il est clair que cela prendra 4 heures à faire, et il n’est pas nécessaire d’apporter des Points D’histoire dans le mélange.
7. Réglage du PBI de référence à chaque Sprint
Lorsqu’une équipe ajuste le PBI de référence à chaque sprint, la vitesse des différents Sprints n’est plus comparable. L’équipe perd des informations vous ne pouvez plus utiliser la vitesse historique pour planifier à l’avance. Il est préférable d’utiliser une plage de PBI récents comme référence.
8. Histoire pointant à nouveau les problèmes inachevés
lors du déplacement d’un PBI inachevé vers le sprint suivant, il n’est pas nécessaire de réévaluer., L’estimation n’a peut-être pas été exacte, mais ce n’est pas un problème. À la suite de la planification du Sprint, l’équipe connaîtra toutes les tâches nécessaires pour résoudre le problème. L’estimation de ces tâches en heures. Donc, le prochain Sprint, l’équipe saura combien de temps est encore nécessaire pour terminer le PBI. Le fait que le PBI n’ait pas été terminé fera partie de la vélocité.
9. Ajustement de L’estimation du point D’histoire car un développeur spécifique y travaillera
L’histoire pointant un PBI est relative à l’Histoire de l’utilisateur de référence et effectuée par l’équipe., L’histoire des membres de l’équipe pointent le PBI et parviennent à un accord sur l’estimation lors d’une session de poker de planification. Un PBI peut être 3 points D’histoire pour un développeur senior, mais 8 points D’histoire pour un développeur junior. L’équipe devrait parvenir à un accord sur le travail que cela représente pour l’équipe et l’utiliser pour la planification. Vous ne devez pas ajuster les points de L’histoire Parce qu’une personne spécifique fera le travail. Peut-être qu’au moment où ils commencent à travailler sur le problème, le développeur principal travaille sur un problème de production. Il peut alors être nécessaire pour le développeur Junior de le ramasser.
10., Ne jamais ajuster les PBI de référence
lorsque la composition de l’équipe change ,cela peut affecter les estimations de vitesse et de point D’histoire. Ils dépendent tous deux de l’équipe qui effectue le travail. Imaginez que vous story-pointé le problème lorsque deux développeurs seniors étaient présents. Au moment où vous voulez commencer à travailler sur ces questions, ils ont tous deux quitté l’entreprise. Maintenant, deux nouveaux développeurs juniors font partie de l’équipe. C’est une bonne pratique d’établir une nouvelle histoire D’utilisateur de référence sur laquelle toute l’équipe a travaillé., Cela garantit que tout le monde est sur la même page lorsque l’histoire pointe, et donne à l’équipe un peu de temps pour établir une nouvelle vitesse. À mesure que l’équipe devient plus mature et améliore son estimation, il peut être judicieux d’établir de nouveaux PBI de référence.
11. Conforme à l’expert dans la salle.
lors de la planification Poker, il y a le risque que l’équipe se conforme à l’expert évident dans la salle. Une façon de résoudre ce problème est de laisser l’expert élaborer sur le travail. Le reste de l’équipe de devis sans l’expert. La Constitution d’une expertise spécifique est inévitable., Ne laissez pas cela saper le fait que l’estimation est un effort d’équipe.
12. Ne pas discuter de problèmes mal orientés dans retrospective.
de temps en temps, l’Histoire de l’équipe pointe un problème où il est clair que l’estimation était complètement désactivée. Il est important de discuter de ces questions et d’essayer d’apprendre, afin que les estimations futures soient plus précises. Dans l’une de mes équipes, nous avons oublié de prendre en compte la création de données de test lors de l’estimation. Alors nous avons fait un point à discuter pour chaque question si la création de données de test était applicable., Le cas échéant, nous leur demandons s’ils ont pris en compte la création de données de test. Cela a beaucoup amélioré nos estimations.
Conclusion
Le concept de Points d’Histoire est simple, mais difficile à appliquer. Presque toutes les équipes Scrum les utilisent, mais elles ne font pas partie du Guide officiel Scrum. Pour cette raison, les gens ont des opinions différentes sur la façon dont vous devriez les utiliser. Le terme Story Point lui-même est déjà déroutant, car vous pouvez l’utiliser pour des types de travail autres que les User Stories. En plus de cela, ‘Point’ suggère qu’un point D’histoire représente une valeur., Comme l’a souligné un collègue, peut-être que le terme « facteur de planification » aiderait à réduire la confusion de nombreuses personnes. Être conscient des erreurs qui peuvent être commises lors de l’utilisation de Story Points aide à les appliquer de la bonne façon.
