La vélocité, c’est « l’effort » moyen qu’est capable de réaliser une équipe sur une période donnée.
(Une quantité de sprint par exemple).
Cet effort peut être exprimé au moyen de story points
Exemple de calcul
Voici quelques données nécessaires à la compréhension d’un calcule de vélocité.
Comme tu le constates, il y a une grande différence entre les sprints 8 & 9 et les autres.
De temps à autre, il arrive que l’équipe ne finisse pas tout ce qu’il y avait dans le sprint, je t’invite à lire l’article Le sprint est fini, et il reste des tickets
Les points brûlés correspondent à l’addition des SP des items réalisés. Répondant à la Definition of Done (DoD)
| Sprint | Points brulé dans le sprint |
| Sprint 7 | 25 |
| Sprint 8 | 11 |
| Sprint 9 | 37 |
| Sprint 10 | 24 |
| Sprint 11 | 26 |
Nombre total de points pour les 5 sprints: 123
Nombre moyen par sprint / vélocité: 24,6
Est-ce toujours fiable?
Pas nécessairement, c’est une excellente indication, mais certains facteurs vont influencer les chiffres.
Les jours de maladie / congé
Si un développeur ne travaille pas et donc ne développe pas, il y a moins de choses qui sont réalisées au courant du sprint => moins de SP brûlé.
Si nous fonctionnons en flux tendu (c’est-à-dire que le temps entre la rédaction des tickets et leur apparition dans un sprint est relativement court), on pourrait également se retrouver avec moins de choses à faire, ou des choses non encore bien décrit et répondant à la DoR. Dans ce cas, le travail de développement sera également impacté.
Oui, mais bon, tous les développeurs sont au moins une fois malades sur l’année, donc, on peut lisser cette donnée.
Ce n’est pas faux, mais ce n’est pas tout à fait vrais non plus, on reviendra sur cela plus loin dans l’article.
Au plus l’équipe est petite, au plus ce facteur aura d’influence (100% pour une équipe de 1 dev).
Les changements dans l’équipe
Alors ici, c’est très simple, si l’équipe n’est pas stable depuis un certain temps, cette information n’a absolument aucun sens, aucune fiabilité, aucune valeur.
- En cas de nouveau venu, du temps à consacrer à son intégration, à la place du développement des tickets.
En théorie, on reviendra à la situation initiale et à une augmentation après un certain temps. Si ce n’est pas le cas, il y a des questions à se poser. - Un membre de l’équipe part, il y a donc moins de « force de travail » disponible
À tous les coups, un changement dans l’équipe modifie la vélocité.
La spécialisation des membres de l’équipe
Une équipe doit être en mesure de réaliser l’entièreté du produit, cependant, ses membres ont certaines spécialités. Il est tout à fait envisageable dans un projet de développement d’une application ou d’un site qu’un sprint contienne plus de demande front-end que back, dans ce cas, un spécialiste back-end peut se retrouver sans ticket dans sa spécialité. Bien entendu, il ne va pas rester à rien, mais il est certainement moins compétent dans les autres domaines.
PS c’est probablement un bon moment pour régler un peu de dette technique (qui ne devrait pas exister) ou aider à l’analyse, ou optimiser du code …
Que peut-on faire avec cette information?
Prévoir le nombre d’item à mettre dans un sprint
Cette mesure nous permet par addition des SP de savoir quelle quantité de tickets nous pouvons mettre dans le sprint.
Planifier
On peut faire un forcast, c’est-à-dire qu’on peut tenter de prédire, d’estimer et donc de planifier quand une fonctionnalité aura été développée.
Considérons qu’en additionnant les story points des tickets nécessaires à la réalisation d’une fonctionnalité, on arrive à 94. Nous savons que notre moyenne / vélocité est de 24,6
94 / 24,6 = 3,82.
Il nous faut donc 3,82 => 4 sprints pour réaliser la fonctionnalité.
Quelle période de temps devons-nous considérer?
On serait aisément tenté de dire qu’au plus la période de référence est longue, au plus la mesure est fiable. Après tout, on a plus de données …
Et bien non, la vélocité va varier avec le temps. Nous avons déjà soulevé le cas de l’augmentation ou diminution du nombre de membres dans l’équipe, nous allons donc considérer que l’équipe reste stable.
Il y a d’autres phénomènes qui feront varier cette information, par exemple, la montée en compétence technique des membres, la manière d’écrire les tickets va évoluer avec le temps, idéalement devenir meilleure, les membres de l’équipe vont mieux se comprendre et l’estimation deviendra plus précise.
On considère l’information comme correcte après 3 à 5 sprints. Sachant que cette valeur évolue légèrement au fil du temps, utiliser un forcast à long terme n’est pas idéale. Au plus le calcule se fait dans le futur, au moins l’information a de valeur.
Donc, on ne peut pas facilement considérer la possible absence d’un membre durant 4 semaines sur l’année ou même un prorata
Il est tentant de comparer les vélocités propres des équipes, ou de faire un prorata par développeur.
Hé bien, cela ne fonctionne pas, car les estimations pour l’équipe A ne sont pas les estimations l’équipe B.
La lecture de ces articles te sera certainement utile: