Comment améliorer la vélocité de son équipe produit ?

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.  

Pourquoi certaines équipes ont une vélocité décorrélée de leur performance ?  

L’absence de backlog refinement

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.

Une mauvaise estimation des tickets

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 :  

• Les tickets sont sous-estimés : dans ce cas, le Product Manager va embarquer un nombre de tickets trop important, qui ne seront pour la plupart par réalisés. Des tickets avec une trop faible estimation prennent plus de temps aux développeurs que prévu, ce qui est décourageant pour l’équipe technique et ce qui donne lieu, lors de la Sprint Review, à une vélocité très faible.
• Les tickets sont surestimés : dans ce cas, le Product Manager n’embarquera pas assez de tickets, les développeurs risqueront de s’ennuyer et des tickets potentiellement non estimés devront être rajoutés en cours de sprint, ce qui occasionnera de la désorganisation et la perte d’objectifs globaux.

Des tickets trop importants et pas détaillés

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é.  

Comment aligner performance de l’équipe et vélocité ?

Prendre du recul sur les tickets à réaliser

Nous avons parlé précédemment de l’importance du technical refinement. Voici quelques pistes pour un backlog refinement réussi :  

• Le Product Manager rédige correctement les tickets qu’il souhaite voir estimer, en y incluant le maximum de détails possibles, en y mettant les critères d’acceptance, des maquettes, des explications produit et du contexte business ;
• Avant de se lancer dans l’estimation, l’équipe technique doit poser toutes ses questions au Product Manager, pour s’assurer d’avoir bien compris le ticket ;
• Ensuite, l’équipe technique se réunit pour définir et écrire la stratégie technique ;
• Le Tech Lead doit s’assurer que chaque développeur est en accord avec cette stratégie, la comprend et sait comment la mettre en place de façon autonome. Si certains tickets sont complexes, il peut être décidé pendant le technical refinement de prévoir du pair programming ;
• Une fois la stratégie technique élaborée, l’équipe peut estimer le ticket : l’estimation est collective, chaque développeur donnant son avis sur le nombre de story points à attribuer à un ticket ;
• L’arbitrage sur l’estimation se fait par une discussion conjointe entre développeurs, parfois challengée par le Product Manager, afin de comprendre les implications qui ont donné lieu à cette estimation.

Diviser les fonctionnalités en ticket

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 :  

• d’une EPIC ;
• d’une initiative (collection d’EPICs axées sur un objectif commun) ;
• d’une sous-tâche d’une fonctionnalité plus grande ;
• d’une tâche technique ;
• d’une user story classique ;
• d’une Spike dans le cas d’une discovery par exemple.

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.  

Réaliser correctement le sprint planning

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.  

Quelles sont les avantages d’avoir une vélocité juste ?

Une équipe motivée

Ê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.  

Des avancées concrètes

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.  

Un sponsor satisfait

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  :  

• Elle est un point de repère pour chaque membre de l’équipe, qui connait sa capacité individuelle et la capacité globale de l’équipe, sprint après sprint ;
• Elle motive l’équipe technique à approcher la vélocité moyenne ou prédictive ;
• Elle témoigne des avancées concrètes de l’équipe et donne le sentiment d’être en mouvement ;
• Elle permet de s’améliorer continuellement, en comparant la vélocité de chaque sprint ;
• Elle est un bon moyen de communication pour témoigner aux interlocuteurs extérieurs de l’avancée de l’équipe.