Si vous avez déjà connu du trafic à Los Angeles, vous savez que le temps que vous devez prendre pour vous rendre d’Arcadia à Santa Monica est soumis à un certain nombre de forces, y compris la circulation, la météo, la construction, l’Heure de la journée et les caprices des autres conducteurs. C’est une distance de 32 miles qui pourrait prendre 41 minutes ou 4 heures.,
Les éléments de votre backlog de produits Scrum sont soumis à un nombre similaire de variables, ce qui rend souvent la planification Agile aussi frustrante que de rester assis dans le trafic du Sud de la Californie.
Et c’est un énorme problème. Si vous ne parvenez pas à estimer avec précision et cohérence le temps ou la vitesse pendant la planification Agile, cela peut entraîner des délais manqués, des goulots d’étranglement, des obstacles, Un glissement de la portée et parfois même l’échec d’un projet.
la bonne nouvelle est qu’il existe une meilleure façon d’estimer le temps nécessaire à la planification Agile: l’estimation du story point.,
inconvénients des autres méthodes d’estimation du temps dans les projets agiles
avant d’entrer dans la valeur de l’estimation du point d’histoire, considérons d’autres méthodes d’estimation du temps utilisées dans la planification Agile.
de nombreuses équipes attribuent une estimation aux projets et aux éléments à l’heure, puis elles attribuent un nombre total d’heures par sprint. Mais, si nous revenons à l’analogie de conduite, cette pratique est similaire à ne regarder que la distance lors de la conduite et ne pas tenir compte d’autres facteurs.
Une autre façon d’estimer est la technique du « jour idéal”., Chaque journée de travail se compose d’e-mails, de chats et de réunions, ce qui signifie que vos développeurs ne seront pas disponibles pour travailler pendant 8 heures par jour, même s’ils sont toujours au travail. L’inconvénient de cette méthode d’estimation est qu’elle repose toujours sur les heures et non sur l’effort.
que sont les story points?
alors, comment l’estimation du story point donne-t-elle à votre équipe une estimation plus précise du temps que mettront les user stories à terminer?
avec les story points, les équipes prennent en compte l’effort et la complexité d’assigner chaque élément d’un backlog produit avec une valeur numérique., Les points d’histoire sont beaucoup plus complets que de ne regarder qu’un seul facteur—le temps—pour estimer la planification du sprint.
L’estimation du Story point comprend trois composantes principales:
- risque: le risque d’un projet ou d’un élément particulier comprend des demandes vagues, une dépendance à l’égard d’un tiers ou des changements à mi-tâche.
- complexité: ce composant est déterminé par la difficulté de développement de la fonctionnalité.
- répétition: ce composant est déterminé par la familiarité du membre de l’équipe avec la fonctionnalité et la monotonie de certaines tâches dans le développement.,
en intégrant les trois points ci-dessus, votre équipe peut planifier plus précisément les sprints, inclure un coussin pour l’incertitude, mieux estimer les problèmes et éviter de trop s’appuyer sur les engagements de temps. Les Story points permettent une cohérence non seulement au sein des équipes, mais entre les départements.
3 étapes pour L’estimation Agile du story point
suivez ce processus pour planifier plus précisément vos sprints, donner des attentes réalistes et faire avancer les projets plus rapidement.,
utilisez des numéros de séquence de Fibonacci
Il est tentant d’attribuer des éléments avec une échelle linéaire, mais ces entiers ne sont pas suffisamment différenciés pour définir clairement une estimation.
Vous avez probablement rencontré cela au cabinet du médecin avec une échelle de douleur. Si 1 sur l’échelle de la douleur représente « tout à fait bien » et 10 est une douleur si grave qu’on a l’impression que vous êtes en train de mourir, qu’est-ce que 4? Et, en outre, en quoi 4 est-il différent de 5? Et où un calcul rénal s’intègre-t-il sur la balance si vous n’avez jamais ressenti de douleur intense auparavant?
Les numéros de séquence de Fibonacci éliminent ces sauts mineurs., Comme vous vous en souvenez, la suite de Fibonacci est une série de nombres où chaque nombre est la somme des deux nombres précédents: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.
Pour Agile, la séquence est généralement modifiées à 0.5, 1, 2, 3, 5, 8, 13, etc. En utilisant ces chiffres, il est beaucoup plus facile de décider si un élément est 3 points d’histoire ou 5 points d’histoire.,
Determine a matrix
After you’ve decided to use the Fibonacci sequence, it’s time to determine a baseline for each story point., Par exemple:
1 = Ajouter un nouveau produit à un menu déroulant
2 = Ajouter le suivi des commandes pour les utilisateurs connectés
3 = Ajouter un système de notation au site web
5 = Ajouter un forum au site
8 = Ajouter la conformité GDPR et CCPA à travers le site
votre base de référence est incluse dans cette matrice en tant que 1, qui définit la norme pour ce à quoi ressemble le moins de risque, de complexité et de répétition dans la pratique. Cette matrice est un moyen de mesurer plus concrètement l’effort; gardez cela à l’esprit au lieu de juger par défaut des éléments en fonction uniquement de la durée.,
organisez une partie de poker de planification
Le poker de planification aide une équipe à obtenir un consensus sur l’approximation correcte du point d’histoire pour chaque élément. Voici comment cela fonctionne:
- dans une réunion de planification de sprint, chaque développeur et testeur reçoit un ensemble de cartes, chacune représentant un numéro d’une séquence de Fibonacci.
- Un élément de backlog est amené à la table afin que l’équipe puisse poser des questions et clarifier les fonctionnalités.
- lorsque la discussion est fermée, chaque développeur et testeur sélectionne en privé la carte qui reflète le mieux leur estimation.,
- Lorsque toutes les cartes ont été sélectionnés, les estimateurs révèlent leurs cartes en même temps. Si un consensus est atteint, il est temps de passer au prochain élément de l’arriéré. Si les estimations varient, les dirigeants discutent jusqu’à ce qu’ils parviennent à un consensus.
il est utile d’avoir une matrice complète à portée de main pour les estimateurs de référence lors de la planification poker, car il permet une plus grande cohérence entre les tâches. Aussi, il est utile de définir une limite maximale (13, par exemple). Si l’on estime qu’une tâche est supérieure à cette limite, elle doit être divisée en éléments plus petits., De même, si une tâche est inférieure à 1, elle doit être incorporée dans une autre tâche.
à ce stade, lors de votre réunion de planification sprint, les éléments du backlog produit peuvent être hiérarchisés et répartis entre l’équipe en fonction de la capacité de charge de travail de l’équipe.
comment estimer la vitesse du sprint
vous vous demandez peut-être à ce stade combien de points d’histoire une équipe peut compléter pendant un sprint. Ce montant est appelé vitesse de sprint, et malheureusement, il n’y a aucun moyen de le déterminer jusqu’à ce que le premier sprint soit terminé.,
pendant le premier sprint après votre première réunion de planification de story points, Gardez une trace du nombre de story points terminés. Ce nombre total peut ensuite être utilisé pour déterminer un nombre raisonnable de points d’histoire que votre équipe peut compléter lors d’un sprint. Ensuite, vous serez en mesure d’estimer le nombre de cycles de sprint qui devront être terminés pour un projet.
Si vous utilisez un tableau Scrum ou Kanban, regardez simplement la colonne « terminé” à la fin de votre sprint et totalisez le nombre de points d’histoire. Au fil du temps, vous pouvez faire une moyenne de plusieurs semaines de données pour estimer une vitesse de sprint plus précise.,
Continue to improve based on past sprint estimates
The first sprint after adapting the story point technique is not going to go perfectly. And that’s completely normal., Définissez cette attente avec votre équipe au début afin que la frustration ne détourne pas le processus.
lors de la prochaine réunion de planification du sprint, demandez à votre équipe ce qui s’est bien passé, ce qui a mal tourné et ce qui peut être fait pour s’améliorer. Vous devrez peut-être ajuster votre matrice initiale pour mieux estimer les éléments à venir. Et cette matrice peut être ajustée jusqu’à ce que votre équipe soit plus à l’aise avec l’estimation de l’effort de chaque tâche.
étant donné que le développement Agile est un effort d’équipe, il est important de s’appuyer fortement sur les commentaires de l’équipe pour déterminer l’amélioration., Bien que les points d’histoire ne soient pas aussi intuitifs que d’attribuer simplement des estimations d’heures à chaque tâche, vous constaterez qu’en estimant l’effort au lieu du temps, vous aurez un sprint plus calme, une équipe plus organisée et préparée et une expérience globale moins stressée pour chaque sprint. En outre, vous serez en mesure de discuter des attentes avec les parties prenantes et de fixer des dates de livraison plus raisonnables à l’avenir, ce qui améliore l’efficacité et, en fin de compte, améliore le produit.,
maintenant que vous avez estimé tous vos points d’histoire, l’étape suivante consiste à créer votre plan de publication Agile.
en Savoir plus
