Hello la communauté,
Je veux prendre votre avis sur le calcul de vélocité svp.
Ex: j’ai la somme des sp pr les travaux planifiés a 50sp,et durant c sprint j’ai pu livrer des demandes imprévus de 20sp.
Ma vélocité doit contenir q ce qui a été planifié ou j’inclue meme les imprevu.
Merci bcp
La vélocité inclut tout ce qui a été réalisé, donc prévu + imprévu.
En revanche, 20 points d’imprévus sur 50 de planifiés ça fait presque la moitié du sprint, donc ça mérite d’en parler en rétro pour essayer de comprendre ce qui s’est passé.
Si c’est un événement exceptionnel ça peut arriver, mais si c’est récurrent vous avez un vrai problème. Ça peut dire soit que vous acceptez des choses que vous auriez dû refuser, soit que votre équipe traite trop d’imprévus pour utiliser Scrum efficacement.
4 « J'aime »
Ca signifie que les imprévus sont estimés @Meryem ? C’est quoi ces imprévus, des incidents ?
1 « J'aime »
Oui incident,bug,retour sur test ko des derniers sprint
Comment vous procédez pour estimer les incidents, bug, retour sur test ko ?
ce sont des incidents de PROD ?
un indicateur qui pourrait t’aider est le ratio bug/US
par pour viser un chiffre le plus bas possible, mais pour devenir prédictible dans les imprévus
genre si tous les 50 cartes, t’as 20 cartes d’imprévus, t’as 40% d’imprévu
je parle en carte et pas SP, car je préfère mesurer que d’estimer, ça me semble plus fiable
1 « J'aime »
Merci, c’est un bon réflexe aussi
On le fait au ressenti du développeur.justement c’est très délicat car a l’avance ils ne savent pas a quoi va ressembler l incident,donc les estimations en sp ne sont pas tjr fiable et je ne sais pas quoi les conseiller pr s’améliorer ds ce volet d’estimation des incidents qui arrivent ds le sprint
si une activité n’est pas pertinente (ici estimer les incidents) autant ne pas le faire et juste communiquer le nombre d’incidents traités dans le sprint, temps de cycle, Lead Time, tout ce qui se mesure
t’auras un temps moyen de résolution d’anomalie, qui va se lisser avec le temps
2 « J'aime »
Je partage l’avis de Emmanuel sur les activités non pertinentes. C’est bien là où je voulais en venir et tu le dis toi même : ‹ tres délicat › ‹ pas tjr fiable ›. Peut être faudrait il recentrer sur les raisons qui vous poussent aujourd’hui à estimer l’inestimable (qui ne peut être estimé) ?
Si la vélocité c’est aussi le non prévu alors il faut l’estimer sur les même critères que le prévu… Sinon ça n’a aucun sens. Ouah pas simple hein 
Le seul critère intangible, celui qui ne ment pas, c’est ce qui s’est déjà passé. Alors cela signifie il qu’il faut gaspiller du temps à calculer après coup combien de temps on a passé sur telle ou telle activité ? Hmmm… l’impact en vaut t’il l’effort ?
Encore une fois : à quoi ça va servir ? Qu’est ce qu’on attend de cette vélocité aujourd’hui ? Qu’elle utilisation on en fait ? Qu’elle est l’utilisation qu’on peut vraiment en faire ? (Par l’équipe, pour l’équipe, pas pour contrôler mais pour identifier, pas pour planifier mais pour se donner de la visibilité etc…).
Je creuserai par là 
En phase, le passé est la richesse, le futur, on ne le connait pas.
Dand ma boite, on a mis en place de la BI sur Jira pour be pas avoir à faire d’effort pour mesurer ce qui s’est passé et s’en servir pour predire le futur.
L’outil utilisé est EazyBI mais ce n’est pas l’essentiel.
Ce qui compte est de se baser sur des données fiables, le passé, pour predire ce qui va ou risque d’arriver.
Plus les données du passé sont sur une longue période, plus elles sont riches (absences, congés, turn over, imprévus,…) tout est là, il n’y a qu’à se servir.
Ma vision du No Estimate : n’estimez pas, mesurez !
Sur la vélocité, à quoi ça sert : devenir prédictible.
Au moins vous avez une idées du débit de votre équipe.
Ça permet de donner de la visibilité, verifier cette prédiction basée sur le passé qui se met tout le temps à jour.
Ça permet aussi à l’équipe de s’interroger sur l’efficacité, l’amélioration continue, injecter des actions et pratiques dans l’équipe et observer les chiffres. En plus d’un ressenti, vous avez du factuel, moins discutable que l’humeur et la satisfaction
Tu risques de biaiser tes estimations futures si tu comptes tes bugs dans ta vélocité car n’étant par essence pas vraiment estimable tu y ajoutes de l’incertitude… vous êtes peut être capables d’estimer la complexité d’un bug car l’équipe est mature sur le produit, mais si tu fais prendre à en charge par une autre équipe ça ne sera peut être plus le cas… donc le mieux est d’avoir de la bande passante dans ton sprint pour gérer les imprévus de la prod mais pas les mettre dans la liste des tickets à traiter pour atteindre ton sprint goal… tu vois l’idée? Du coup que les évolutions pour avoir une vélocité plus fiable pour un meilleur engagement… mais tout cela est au choix de l’équipe bien entendu…
1 « J'aime »