Il existe des concepts simples à votre disposition quand vous êtres Product Owner ou Scrum Master pour vous aider à suivre le delivery de votre équipe tech et cerise sur le gâteau, s’ils sont bien mis en place au début, ces concepts vont également vous permettre de pouvoir traquer la progression de votre équipe tech et de pouvoir construire plus sereinement vos roadmaps.
Dans cet article, nous allons aborder les notions suivantes :
Les tickets de référence sont un concept qui permet de définir des tâches de référence auxquelles sont associées une complexité. Pour définir leur complexité, une bonne pratique est de se baser sur des points de complexité en suivant une variante de la suite de Fibonnaci : 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, « ∞ » et « ? ». Dans cette suite, les valeurs sont de plus en plus éloignées les unes des autres. Plus la valeur augmente, plus les estimations vont devenir de moins en moins précises, ce qui sera un bon signe d’alerte pour l’équipe pour se dire que le sujet n’est par exemple pas assez bien scopé ou qu’il doit être redécoupé.
Je vous mets ci-dessous des exemples plutôt simples de tickets de référence pour vous donner un ordre d'idées de ce qui peut être attendu :
Lors des poker planning, l’équipe tech va estimer la complexité de chacune des user-stories (ou des tâches relatives à ces user-stories) contenues dans le sprint relativement aux tickets de référence.
Concrètement, la dernière fois que j’ai mis en place des tickets de référence dans une équipe, le set up était le suivant :
Une fois ces tickets de référence définis, il faut déterminer la célérité de l’équipe.
Pour démarrer, les techs leads vont d’abord définir la célérité théorique de l’équipe. Comment ? Suite à l’estimation des tickets de référence, les techs leads vont choisir parmi les tickets de référence celui qui pourrait être livré en une journée de travail et c’est la complexité de ce ticket de référence qui sera défini comme célérité théorique.
La célérité représente en effet le nombre de points que peut livrer un développeur dans une journée.
Attention, on parle lorsque l’on parle de célérité, on parle de célérité d’équipe. Prenons un exemple simple : la célérité théorique est de 5 et vous avez 3 développeurs dans votre équipe. L’équipe est donc censée livrée 3x5 = 15 points dans la journée. Si le 1er développeur, plus senior, livre 7 points dans la journée, que le 2e développeur livre 5 points et que le 3e développeur, plus junior, livre quant à lui 3 points, on aura bien un total de points produits à la fin de la journée de 7+5+3 = 15 points, la célérité d’équipe est donc bien de 5 points.
Une fois que la célérité théorique est définie, il ne manque plus qu’à calculer la capacité de l’équipe pour le sprint.
Pour définir cette capacité, il faut calculer le nombre de jours de présence de chaque membre de l’équipe pendant le sprint, auquel on ajoute un coefficient de productivité de 80% pour prendre en compte le temps non passé à développer (meetings & rituels, aide d’autres équipes, …), qu’on multiplie ensuite par la célérité théorique de l’équipe.
En reprenant mon exemple de 3 développeurs dans l’équipe pendant 1 sprint de 2 semaines avec une célérité de 5, on obtient : 5 (célérité théorique) x 30 jours (3 développeurs x 10 jours sans day off) x 80% (coefficient de productivité) = 120 points de capacité
La capacité de l’équipe représente donc le nombre de points théoriques de complexité à ne pas dépasser dans le prochain sprint. Avant de démarrer un sprint, il faut donc que le Product Owner ou Scrum Master s’assure que le nombre de points embarqués correspond au maximum au nombre de points théoriques.
A la fin du sprint, on pourra calculer la célérité réelle de l’équipe de cette manière : nombre de points produits / (nombre de jours hommes du sprint x coefficient de productivité).
Pour continuer avec notre exemple, si l’équipe a effectivement produit 106 points pendant le sprint alors la célérité constatée / réelle de l’équipe serait de 4,4 → 106 points / (30 jours x 80%) = 4,4.
Une bonne pratique quant à l’évolution à la hausse ou à la baisse de la célérité est de considérer la moyenne des 3 sprints précédents.
***
Ces notions de ticket de référence et d’estimations en points de complexité relatives peuvent aussi être utilisées pour estimer des EPICs ou des macro-features pour vous aider à sizer grosse maille votre roadmap.
En conclusion :
Si cette ressource vous a plu n'hésitez pas à nous suivre sur Linkedin !
