Dans le billet précédent intitulé « La vélocité, une mesure fausse! », nous avons abordé les façons d’utiliser la notion de vélocité en nous penchant sur les mauvaises utilisations.

Voici un court extrait du précédent billet :

« En Scrum, on appelle **vélocité** le nombre de points d’effort « terminés » au cours d’un sprint (et « terminé » dépend de la définition décidée par l’équipe).

Il s’agit d’un indicateur qui a pour but d’aider l’équipe de développement lors des séances de planification de sprint (« Sprint Planning ») à évaluer la quantité de travail qu’elle peut sélectionner pour le sprint. Cet indicateur peut être utilisé par le Product Owner pour l’aider à planifier les livraisons, et ce, à condition de prendre en compte le cône d’incertitude associé. »

Comment l’équipe se sert-elle de cette vélocité?

Une équipe Scrum mature sélectionne dans le carnet de produit les « Product Backlog Items » (ou PBI) qu’elle estime être capable de réaliser au cours du sprint parce qu’ils sont « prêts ».

Rappelons qu’en Scrum, l’équipe de développement est au service du Product Owner (PO). L’équipe cherche donc, par sa sélection, à livrer le maximum de valeur d’affaires, tout en tenant compte du contexte et des contraintes. Il est toujours question de mettre en perspective différents aspects : valeur, date, risques, dépendances, etc.

Cette sélection est faite au cours d’une discussion avec le PO. C’est lors de celle-ci qu’entre en jeu la connaissance par l’équipe de sa vélocité exprimée en valeur moyenne associée à un intervalle de confiance (ou cône d’incertitude). Découvrez comment l’Agilité vous permet de faire face aux impératifs complexes et de propulser la livraison de vos stratégies, téléchargez notre livre blanc «Livrez vos stratégies 2x plus vite avec les approches Agiles. »

En effet, comment cette équipe peut-elle déterminer à quel moment s’arrêter? Combien de PBI prendre en compte pour le sprint?

Eh bien, en utilisant sa vélocité et le « GBS » (gros bon sens). Si historiquement l’équipe réalise en moyenne 22 points (± 3) par sprint, elle devrait commencer à se poser des questions lorsque les PBI sélectionnés totalisent environ 20 points. « Peut-on prendre un item de plus? Doit-on s’arrêter là? Pourquoi? Qu’est-ce qui nous permettrait de prendre un item de plus? Si nous devions en prendre un de plus, quel serait le risque? Quel serait le gain? »

C’est souvent à ce moment-là que l’on découvre « la course aux points » dont je parlais dans mon billet précédent.

Une équipe mature sort de cette dynamique de chercher à faire le plus de points possible pour utiliser la vélocité comme un outil déclenchant des discussions. Discussions entre les membres de l’équipe autant qu’avec le PO.

Au cours de ces conversations, le Scrum Master devrait être attentif aux arguments de l’équipe. L’équipe cherche-t-elle des arguments pour se protéger? Prend-elle en compte les décisions de la rétrospective et leur influence sur le sprint en cours? (Le sprint commence à la première minute de la rencontre de planification de sprint.) L’équipe a-t-elle revu sa définition de « terminé » (« Definition of Done ») et se pose la question de l’impact sur le sprint courant?…

Revenons à notre équipe réalisant en moyenne 22 points, elle décide à ce sprint-ci de prévoir seulement 20 points, car les PBI sélectionnés ont collectivement une valeur intéressante. De plus, ils servent bien l’objectif du sprint, laissent de la place pour réaliser les actions d’amélioration prévues et tiennent compte du fait que la définition de « terminé » a été améliorée de manière à dorénavant fournir une aide utilisateur vidéo à la fin de chaque sprint.

Lorsque la vélocité est utilisée de cette façon par l’équipe de développement, cela permet au PO de l’utiliser comme indicateur de planification pour la livraison. Pour cela, il est judicieux d’avoir un plan de livraison.

Imaginons que notre PO décide de réaliser 4 livraisons par année, il va alors déterminer ce qu’il souhaite proposer aux utilisateurs tous les 3 mois. Il va donc, conjointement avec l’équipe, élaborer un plan de livraison (« Release Plan »).

Afin de l’aider à élaborer ce plan, l’équipe va dans un premier temps estimer les PBI. Ensuite, en tenant compte de la vélocité moyenne d’un scénario pessimiste (moyenne des 3 à 5 plus mauvaises vélocités enregistrées) et d’un scénario optimiste (moyenne des 3 à 5 meilleures vélocités enregistrées), le PO va pouvoir tracer un trait au-dessus duquel il va ordonner les éléments du carnet de produit. Cela lui permettra de faire les arbitrages nécessaires pour s’assurer d’avoir un produit complet et cohérent en tout temps.

Ce plan de livraison sera mis à jour au cours de chaque revue de sprint (« Sprint Review ») en tenant compte de la mise à jour de l’indicateur. Ceci permet, à la fin de chaque sprint, d’inspecter et d’adapter (« Inspect & Adapt ») le carnet de produit et de réorienter les efforts.

Un point qu’il est crucial de prendre en compte à cette étape : Est-ce que la définition de « terminé » est réellement complète? Permet-elle réellement de s’assurer que TOUT le travail nécessaire pour mettre le logiciel en production est réalisé? Si ce n’est pas le cas, votre indicateur de vélocité est erroné!

Une astuce, dans ce cas, consiste à ajouter, à la fin de chaque sprint, un PBI contenant le travail restant à faire pour la mise en production et à estimer l’effort nécessaire. Ce PBI vient prendre place juste au-dessus du trait (selon celui choisi : pessimiste, moyen, optimiste), décalant du même coup sous le trait les items prévus.

Cette pratique permet de faire des choix sur les items à réaliser (ceux que l’on souhaite voir au-dessus du trait) et de rendre visible le travail à terminer avant la mise en production, travail ayant malheureusement peu de valeur d’affaires.

Ce moyen vous permet de vous fier à la vélocité de l’équipe pour planifier.

Il est néanmoins important de prendre conscience que si votre définition de « terminé » n’est pas complète, le PO ne peut quand même pas décider de mettre en production plus tôt si une occasion d’affaires se présente. Toutefois, il s’agit d’un autre sujet qui pourrait faire l’objet d’un autre billet.

Selon mon expérience, la façon dont l’équipe tient compte et utilise son indicateur de vélocité est un bon indicateur de la maturité de celle-ci.

Voilà qui conclut l’utilisation de la vélocité – indicateur de l’équipe, pour l’équipe – utilisable par le PO.

Quel est votre plan pour aider votre équipe à passer d’une vélocité « mesure de performance » à une vélocité « aide à la décision »?

Pour vos besoins en coaching, n’hésitez pas à faire appel à un de nos coachs Agiles.

Tremeur Balbous

Tremeur est un conseiller à Pyxis Suisse (pyxis-suisse.ch). Plus spécifiquement, il est un Scrum Master d’expérience, un coach intégral certifié et un facilitateur d’Immunity to ChangeTM. Il accompagne et conseille les organisations lors de transformations Agiles à l’aide de Scrum. Il travaille avec les équipes peu importe leur taille et leur emplacement. De plus, il coache les managers et les équipes de direction. Contactez-le; il adorerait partager avec vous sa passion pour l’Agilité et le développement humain.

Billet précédent

Vidéo du webinaire « Les attitudes doxiques dans les équipes et le syndrome du Titanic! »

Billet suivant

Le Graal de l’Agilité?

4 Commentaires

  1. ericlebrun123@gmail.com'
    Eric Lebrun
    26/12/2016 at 15:01 — Répondre

    Bonjour,

    Je suis un chargé de projets en développement d’application qui a une expérience diverse avec des approches déterministes et Agile. J’aimerais connaître votre opinion sur le rôle du chargé de projets avec l’approche Agile.

    Merci !

    Éric Lebrun

    • tbalbous@pyxis-tech.com'
      03/01/2017 at 09:22 — Répondre

      Bonjour Éric,

      Je vous présente mes meilleurs voeux pour 2017!
      La question que vous posez est très large et mérite à elle seule un ou plusieurs articles de blog.
      Le plus simple est peut-être que nous en discutions de vive voix lors d’un appel. (vous pouvez me contacter via ma page profil sur le site de Pyxis : http://pyxis-tech.com/fr/equipe/tremeur-balbous/)

      Pour tenter une réponse courte, je crois que le chargé de projet à sa place lorsque l’équipe, l’entreprise ou le projet utilise une approche Agile.
      Cette place reste à définir en fonction des activités à couvrir, de leur répartition selon les différents rôles, de la façon de positionner et de jouer ces derniers, de la maturité des participants et de bien d’autres facteurs propres au contexte.
      Je crois que ce qui compte ce n’est pas tant le rôle que l’attitude et la posture que chacun va offrir dans la dynamique collective.

      Au plaisir d’en discuter plus longuement.
      Tremeur

  2. […] La vélocité, une mesure utile! – Blogue Savoir Agile […]

Laissez un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.