Dans un monde où la productivité est clef, comment utiliser la vélocité pour illustrer l’avancement des équipes produit ? C’est ce que nous vous proposons de découvrir à travers cet article ! En effet, la vélocité, qui représente le nombre de story points réalisés par sprint, peut s’avérer un précieux allié ou un véritable cauchemar, lorsqu’elle est éloignée des réalisations de l’équipe. Certaines équipes sont particulièrement performantes mais incapables de le montrer à travers leur vélocité : par exemple, elles peuvent travailler sur des fonctionnalités complexes et conséquentes, ne pas les terminer à la fin du sprint, et afficher une vélocité de 0, qui ne reflète en rien le travail effectué.
Cet article explore les différents écueils d’une vélocité décorrélée de la réalité et propose des pistes pour aligner vélocité et performance de l’équipe.
Le backlog refinement ou technical refinement est une étape primordiale au sein d’une équipe produit. Ce rituel agile, qui peut varier entre 1h ou 4h par sprint, selon la complexité technique du produit, est un moment privilégié où le Product Manager présente les différents tickets à estimer, laisse les développeurs écrire la stratégie technique et estimer les tickets.
Il est fréquent que les équipes produit, par manque d’organisation, ne prennent pas le temps de faire correctement le backlog refinement. Dans ce cas, le Product Manager embarque des tickets sans estimation et sans stratégie technique, ce qui freine l’autonomie des développeurs, qui ne se sont pas mis d’accord sur la stratégie technique à mettre en œuvre pour développer la fonctionnalité.
Être concentré uniquement sur la livraison de fonctionnalités et le développement pur, sans prendre le temps de faire correctement le technical refinement est un des premiers écueils à l’origine d’une vélocité dépourvue de sens.
Cette absence de technical refinement est étroitement liée à la mauvaise estimation des tickets. Si l’équipe technique ne prend pas le temps de faire correctement le technical refinement, les tickets ne peuvent être bien estimés et le nombre de story points est arbitraire, ne reflétant en rien le travail véritable à fournir. Cela occasionne les difficultés suivantes :
Pour faciliter la tâche des développeurs, il est nécessaire que le Product Manager fasse un travail d’écriture des user stories avant de les présenter à l’équipe technique. Un ticket mal rédigé, sans critères d’acceptation, sans maquette et sans détail donne place à l’interprétation, chacun pouvant percevoir à sa façon la fonctionnalité à réaliser. Le vague des tickets fait perdre du temps à l’équipe technique et peut donner lieu à une estimation éloignée de la réalité.
Nous avons parlé précédemment de l’importance du technical refinement. Voici quelques pistes pour un backlog refinement réussi :
Nous avons mentionné précédemment l’importance de bien rédiger un ticket. Il est aussi nécessaire d’attribuer le bon format à chaque ticket. Il convient pour le Product Manager d’identifier si la fonctionnalité qu’il souhaite développer relève :
Le Product Manager doit essayer de découper ses fonctionnalités en plusieurs tickets, indépendants les uns des autres, afin d’éviter de créer des tickets à rallonge, impossibles de terminer en un sprint. Par exemple, un Product Manager souhaite créer une nouvelle page sur un site. Une mauvaise pratique serait d’écrire un ticket ressemblant à « En tant qu’utilisateur, je souhaite avoir accès à la page X » et de mettre tous les détails de la page au sein du ticket.
Il est préférable de découper chaque fonctionnalité de la page en plusieurs petits tickets : cela permettra de diviser le travail entre chaque développeur et de montrer l’avancée concrète de l’équipe à la fin du sprint.
Une fois le technical refinement réalisé, l’équipe procède au sprint planning. Pour ce faire, le Product Manager doit d’abord connaître la vélocité moyenne de son équipe, lorsque tous les développeurs sont présents. Il s’enquiert ensuite des présences et absences de chacun pour déterminer la vélocité théorique de son équipe. Son rôle est alors d’embarquer le bon nombre de tickets : s’il prend trop de tickets, l’équipe aura le sentiment d’avoir sous-performé, et s’il n’en prend pas assez, il risque de lasser l’équipe technique, qui ne sera pas motivée. Le Product Manager est responsable du sprint planning et doit s’assurer que l’équipe sera capable de réaliser 80% des tickets présents dans le sprint. Par ailleurs, le Product Manager doit s’assurer de l’adhésion de l’équipe technique aux tickets embarqués lors du sprint planning : chaque développeur doit comprendre parfaitement les fonctionnalités attendues dans chaque ticket, et connaître le chemin pour les réaliser.
Être bien organisé en amont du sprint est finalement la clef pour une vélocité au plus près des réalisations effectives de l’équipe. Que chaque développeur soit conscient de la vélocité moyenne de l’équipe peut être une source de motivation, chacun souhaitant être proche de la vélocité prévisionnelle, voire au-dessus. L’équipe a alors le sentiment d’avancer, de progresser et de délivrer des fonctionnalités effectives à chaque sprint, matérialisables par des story points. Il devient alors possible de s’interroger sur les baisses de vélocité selon les sprints, afin de mettre en place des solutions d’améliorations continues. La vélocité est un bon indicateur pour analyser la santé de l’équipe.
Avoir une vélocité alignée avec les réalisations concrètes de l’équipe technique est aussi une façon de mettre en avant le travail de chaque développeur lors de la sprint review, et peut être une véritable source de motivation pour l’équipe technique.
La vélocité n’est pas qu’un chiffre aléatoire : elle est l’illustration de l’avancement de l’équipe. Une bonne vélocité n’est pas forcément élevée (tout dépend du nombre de développeurs de l’équipe) : c’est une vélocité qui témoigne de la progression continue de l’équipe. Derrière ce chiffre se cachent des fonctionnalités développées, un produit amélioré pour une meilleure expérience utilisateur. Sans vélocité, il n’est pas possible de quantifier réellement les avancées de l’équipe.
Une vélocité alignée avec les réalisations concrètes de l’équipe est aussi un bon moyen de communication, auprès d’acteurs plus éloignés de l’opérationnel du projet. Il est parfois possible d’avoir des équipes très performantes mais dont la productivité n’est pas reflétée par la vélocité, en raison des écueils mentionnés ci-dessus.
Dans ce cas, les sponsors, plus éloignés du produit et des livraisons opérationnelles de l’équipe, pourront faussement croire que l’équipe sous-performe et ne délivre pas assez de fonctionnalités. Dans ce cas présent, la vélocité dessert l’équipe, qui est injustement méjugée, en raison de son incapacité à communiquer clairement sur ses réalisations.
Une vélocité adéquate est donc aussi un moyen de rassurer et satisfaire les sponsors plus éloignés de l’opérationnel du projet, qui peuvent en un clin d’œil comprendre où va l’équipe, sa vélocité moyenne sprint après sprint et ses réalisations. Cela donne aussi de la visibilité sur la capacité moyenne de l’équipe en termes de réalisation en story points.
En conclusion, la vélocité est particulièrement importante dans une équipe produit pour maintenir une unicité de l'équipe, une bonne performance et l'évolution de son produit ainsi que la satisfaction des parties prenantes.
Ce qu'il faut retenir sur l'amélioration de son équipe produit :