Publié par

Il y a 6 ans -

Temps de lecture 5 minutes

Help, my velocity is like a roller coaster

Un ami m’a dit un jour que le Scrum Master était, au-delà du gardien de la méthode, le garant de la vélocité de l’équipe. Depuis, je me suis approprié cette formule que je trouve excellente. Pour garantir la vélocité, il faut la connaître et qu’elle soit fiable. Bien souvent, pour des équipes Scrum débutantes, il est possible d’être confronté à une vélocité qui fait le yoyo d’un sprint à l’autre. Ou encore, récemment, je me suis trouvé dans cette situation : le Scrum Master et le Product Owner d’une équipe pensaient qu’ils ne connaissaient pas la vélocité de leur équipe. Etonnant non ? Et pourtant, dans quelques cas la vélocité a du mal à émerger. Je vous propose quelques bons réflexes à avoir pour stabiliser la vélocité de votre équipe et l’accompagner sur le chemin du rythme soutenable.

Cas d’exception : la vélocité du Sprint 1

1 produit (ou projet), 1 équipe, 1 vélocité. Cette porte ouverte enfoncée dans les règles de l’art, comment faire pour déterminer la vélocité du premier sprint ? Le cas idéal est d’obtenir l’engagement de l’équipe. Il consiste à demander sur quel ensemble de User Stories l’équipe s’engage à l’issue du sprint, un peu comme un pari. C’est souvent difficile, surtout avec une équipe en construction ou composée de juniors. Dans ce cas de figure, il arrive assez souvent que l’équipe retourne la question au Scrum Master : Mais quelle est notre capacité ?

Luttez contre la tentation d’une espèce de règle de trois "Poids du sprint / coût en Jours Homme / cours du point de complexité". Si vous vous posez la question du "Pourquoi", direction ce billet.

Au delà de l’engagement de l’équipe, vous pouvez proposer à l’équipe un périmètre à fournir en ‘best effort’. Là, cela peut être le client ou le sponsor qui sera difficile à convaincre. Il peut en effet considérer l’approche comme trop permissive ou pas assez engageante. A vous de faire au mieux avec les moyens du bord…

Une autre approche se pratique également : l’équipe a un backlog produit priorisé, et les stories en haut de la pile satisfont la Definition of Ready. il suffit dès lors de piocher les stories une par une, tant que l’équipe est capable de les terminer. Ainsi, à la fin de ce premier sprint la vélocité émerge naturellement : c’est la somme des complexités des US livrées.

La vélocité des autres sprints

Comment aidons-nous nos amis Scrum Master et Product Owner dont je vous parlais un peu plus haut ? En fait, c’est assez facile. Une vélocité, ils en avaient une, ils ne la voyaient simplement pas. Quelques sprints s’étaient déroulés (4 de mémoire), et effectivement, les vélocités constatées avaient l’évolution d’un chariot de montagnes russes. Voici mes quelques conseils pour faire émerger simplement la vélocité d’une équipe.

1. Surtout, ne touchez pas aux estimations

Selon le Scrum Master, le coupable était tout trouvé : "Les estimations ne sont pas fiables". STOP, alerte bouc émissaire. Les estimations ont bon dos, ce ne sont que des estimations. Les accabler cache souvent (toujours ?) un problème bien plus profond. Vous avez un backlog priorisé et estimé ? Surtout, ne touchez à rien. Dans le cas qui nous intéresse, si nous avions touché aux estimations, cela signifiait que nous éliminions l’historique de vélocité. Et donc, que nous nous éloignions encore un peu plus du but à atteindre.

2. Faites une moyenne des vélocités constatées

Du très classique. Là, nous avions les vélocités A, B, C, D : il suffit d’en faire la moyenne E pour poser la vélocité du Sprint 5. OK, c’est un peu dirigiste, mais parfois l’auto-organisation montre ses limites. Ensuite, une fois la situation rétablie, il sera toujours temps de ne se fier qu’à la moyenne des 3 dernières, ou autre, suivant votre préférence.

3. Posez clairement la Définition de Fini

La définition de "fini" (Definition of Done pour les anglophiles) n’est parfois pas clairement établie. Le dommage collatéral est limpide : non définie ou mal définie, comment savons-nous qu’une US est effectivement terminée ? Si vous ne l’avez pas déjà fait, prenez 20 minutes avec l’équipe pour dresser la (ou une première …) liste des quelques critères de votre DoD. Vous en sentirez rapidement le retour sur investissement.

4. Vérifiez que vos stories ne sont pas trop grosses

Là encore, retour aux fondamentaux : vos stories sont-elles INVEST ? Et en particulier, sont-elles ‘S’ (Small) ? Manipuler des grosses stories est porteur d’un risque assez évident. Vous vous exposez au risque plus fort de ne pas les finir pendant le sprint. Et en conséquence, une grosse story, à la complexité importante, pèse sur la vélocité. Si vous ne la finissez pas, c’est autant de points de complexité qui ne sont pas pris en compte dans la vélocité, mais surtout c’est une US qui apporte de la valeur métier qui n’est pas livrée !

5. En fin de sprint, limitez l’en-cours

C’est un bon réflexe à aller piocher chez Kanban. La limite de l’en-cours est un pilier des méthodes agiles. Scrum limite l’en-cours par la timebox qu’est le sprint. Du côté du Kanban, nous limitons l’en-cours à chaque étape du processus de fabrication du logiciel. Si en fin de sprint vous avez beaucoup de Stories en-cours, il ne faut pas hésiter à faire des choix forts : protéger la terminaison des stories de plus grande valeur, même au détriment d’autres. C’est à ce prix que la vélocité est la mieux préservée.

Voilà un petit lot de bonnes pratiques et réflexes pour faire émerger ou améliorer votre vélocité. Cette liste n’est pas absolue et définitive, il ne tient qu’à vous de la compléter / la critiquer !

Publié par

Publié par Ludovic Pérot

Ancien ingénieur de développement, j'ai eu l'occasion de travailler en eXtreme Programming et suis de facto très sensible aux bonnes pratiques d'ingénierie logicielle. Depuis 2008, j'ai alternativement assumé les rôles de Product Owner ou de Scrum Master sur différents projets. C'est ce qui me permet maintenant d'accompagner des équipes dans leur transition agile.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.