Attention, je ne souhaite pas parler de comparaison de vélocité entre équipes distinctes, ce sujet a déjà été traité sur le blog de Mike Cohn de façon très claire et efficace. Je souhaite parler de comparaison de la vélocité des sprints pour une même équipe.
Le mois de mai vient de se terminer et les vacances d’été arrivent, ces 2 périodes sont propices à des prises de congés (bien mérités diront certains) qui influent sur la capacité de production de l’équipe puisque le nombre de jours disponible n’est pas identique d’une itération à l’autre.
Que faire dans ce cas ?
La solution la plus simple consiste à faire une règle de 3 pour recalculer une vélocité « corrigée des variations saisonnières ». Par exemple si l’équipe dispose d’une capacité de production moyenne de 50 jours, et que pour cette itération N il n’y a eu que 42 jours de disponible, il suffit de multiplier la vélocité mesurée de N (disons 65) par 50/42, ce qui donne une vélocité corrigée de N de 77 points. C’est cette vélocité de 77 qui doit être inscrite sur le tableau de suivi de la vélocité et qui sert pour calculer la vélocité moyenne de l’équipe (utilisée pour connaitre la quantité de Product Backlog réalisable à chaque itération)
Une autre solution serait de diviser la vélocité par le nombre de jours disponible, dans notre cas, 65 / 42 = 1,55 et de comparer ce chiffre d’itérations en itérations pour savoir si l’équipe maintient une vélocité constante sur plusieurs itérations … mais je me demande s’il n’y a pas d’effet de bord ?
Qu’en pensez-vous ?
Bonjour,
Je me suis frotté a ce soucis au cours du mois de mai et j’en suis arrivé aux mêmes conclusions.
Il y a forcement un delta : la capacité de production de chaque membre de l’équipe n’est pas forcement la même, sur une petite équipe cela peut avoir un gros impact.
En ce qui concerne le ratio nombre de points / jour disponible me semble en effet à magner avec précaution car on peut en arriver à raisonner de manière inverse.
Pendant très longtemps nous avons mesuré la vélocité absolue et la vélocité relative (points/personne/jour). La vélocité relative est peut être une bonne information mais elle n’a jamais vraiment servi à prendre des décisions.
En fait, on ne peut pas faire des ajustements théoriques aussi simplement car personne n’est égal dans une équipe. Certains sont très expérimentés et rapides, d’autres moins efficace sur certains sujets. Bref, les tentatives se sont toujours soldées par un ajustement au feeling en fonction des personnes présentes sur l’itération à venir.
Pour ce qui est de la visibilité, nous évitons de nous engager à notre pleine puissance car ceci génère du stress tout au long du sprint, ne laisse aucun droit à l’erreur et peu conduire au sacrifice de la qualité. De ce fait, généralement, nous sommes très proche des 100% de précision. Quand il reste du temps, soit nous reprenons une story soit nous profitons de ce temps pour nous améliorer ou maintenir nos outils (intégration continue par ex.).
Pour le cas particulier de l’été, bcp de personnes prennent 3 semaines sur Juillet-Aout alors le PO peut se dire que sur l’été, un sprint sera perdu.
Encore un petit commentaire;) Il me semple difficile de calculer une vélocité théorique sur une année entière car à chaque fois que l’équipe change, la vélocité est impacté et l’estimation des stories en effort peu également changer. Sans changement d’équipe, les 3 dernières itérations d’une équipe sont assez représentatives de la capacité de production jusqu’au prochain changement. Dans l’histoire, le PO doit aussi savoir faire face au changement et la gestion des priorités est capitale car les ‘Nice to have’ se payent très cher quand la date de release approche.
Ça fait longtemps que je n’avais pas fait ce genre de maths…
Si je devais faire la règle de trois :
– Proportion en terme de nombre de jours : 42/50 -> 0,84
– Appliquée à la vélocité mesurée : 65 * 0,84 -> 54,6
L’idée d’une vélocité “constante” me plaît bien…
65/50 -> 1,3 “point” par jour
(et pour le fun : 42*1,3 -> 54,6)
Par les deux moyens on a 54,6 points attendus 🙂 .
Deux remarques :
1) Comme la composition de l’équipe va changer, il faut probablement s’attendre à un mini “forming->storming->norming->performing” et donc à une vélocité plus “faible” encore ;
2) (Comme l’ont déjà fait remarquer les autres commentateurs) ce calcul ne marche qui si l’équipe est parfaitement homogène 🙂
Pour ce qui est des effets de bords de la vélocité “constante”, un effet déjà vu : il faut éviter la fascination de la seule augmentation de celle-ci (par exemple en mesurant aussi le WIP et la qualité…)
Comme le dit si bien Corey Ladas :
“Value trumps flow and flow trumps waste-elimination. Value must come first. There’s no point in churning out crap more efficiently.”
Peut-être ton équipe peut-elle passer d’une time-box « à points » à une time-box « à engagement » ?
Cf. Dave Nicolette : http://dnicolet1.tripod.com/agile/index.blog/1904722/commitmentbased-iteration-planning/
À bientôt,
Yann Picard de Muller
Bonjour,
Je me pose une question concernant la vélocité, je sais ce que sais, j’ai lu plusieurs articles sur le sujet.
Je l’ai pratiqué dans mes premiers projets en Agile.
Maintenant, elle a totalement disparu de mes projets. Je n’y vois réellement aucun intérêt. Je travaille avec la même équipe depuis deux ans (un peu plus d’une dizaine de personnes), nous pratiquons Agile (XP et SCrum) avec une grande simplciité, les process sont acquis.
J’ai mis les méthodes agile en place vers d’autres équipes, une centaine de personnes la pratique dans mon entreprise, mais nous avons tous abandonné la notion de vélocité.
Cela n’apportait que des problèmes de stress et des « conflits humains »
En toute franchise, vous sert-elle réellement dans vos projets ?
N’est pas plus importante de bien connaitre son équipe (faiblesse de certains, rapidité d’autres, etc.) que d’accumuler des statistiques ?
Merci de votre retour
Yannick Quenec’hdu
La vélocité est par exemple un « outil de communication » entre l’équipe et le product owner. C’est le seul moyen pour le PO d’estimer une durée de réalisation d’un ensemble de User Story (ce n’est pas un engagement, juste une estimation).
Par exemple, cela peut être important lorsqu’il faut synchroniser la sortie d’une release et des évènements marketing qu’il faut impérativement faire en même temps pour avoir un impact sur le public (les clients ou utilisateurs).
Je suis curieux de savoir dans quel domaine tu travailles car il semble que dans ton cas avoir une vision à moyen terme n’est pas nécessaire ?
Sans se vouloir être LA référence, Jeff Sutherland raconte régulièrement que la première question qu’il pose à un patron qui dit pratiquer l’agilité dans son entreprise est « Quelle est votre vélocité ? ». Et que si le patron ne sait pas répondre, Jeff a alors de forts doutes sur la pratique réelle de l’agilité dans cette entreprise … à méditer.
Bonjour Yannick,
J’ai regardé sur ton blog, mais je n’ai pas trouvé la réponse à ma question : comment sais-tu sais combien de “use cases” tu peux “caser” dans ta time-box ? (Ce que j’ai lu me fait penser qu’elles ne sont pas de longueur fixe…)
@Alexandre : désolé de squatter ton blog
Une des leçons de ma pratique de Scrum: si vous ne savez pas comment accomplir quelque chose ou que vous n’y arrivez que par un chemin compliqué (ce qui est le cas ici), levez les yeux et posez-vous la question: « Est-ce mon rôle de faire ça ». Dans ce cas de figure, le PO est la mauvaise personne pour faire ce genre d’estimation (je sais, « juste une estimation, pas un engagement »…)! Le PO détermine le QUOI (entrées du PBL) et le QUAND (ordre du PBL), l’équipe le COMBIEN (estimations) et le COMMENT (SBL).
C’est toujours l’équipe qui estime, et qui sait *parfaitement* gérer le scénario d’estimation « X,Y et Z sont en vacances pendant 3/4/5 semaines… combien pouvez-vous accomplir dans ce sprint? ».
SVP, cessez de faire revenir la gestion de projet prédictive par la porte arrière! L’équipe estime les tâches futures, la vélocité est une mesure du passé de l’équipe qui donne une indication, sans plus. Contraindre l’équipe par une « préestimation » équivaut à lui signaler « je ne fais pas confiance à vos estimations »…. ce qui est la mort de toute performance digne de ce nom.
Bonjour,
Merci pour vos réponses, j’ai été un peu absent pour cause de maladie… Je n’ai pas eu le temps de relire vos réponses.
Me voici de nouveau. Je vous remercie pour votre retour. Toutefois, je reste maintenant dubitatif de vos réponses.
Je dirais que j’attendais plus un retour d’expérience (sauf pour François). Vous faites essentiellement une relation entre vélocité et calcul de charges. Sujet, que je connais déjà. Mais justement pour l’avoir pratiqué, je le trouvais trop flou, pas mieux que les méthodes traditionnelles. Je ne comprends pas pourquoi il apporterait un meilleur calcul des charges, un plus surement.
Car au-delà de l’équipe, chaque projet est différent, il y a des éléments que l’on retrouve, le calcul de charges précédent peut être quasi un copier/coller et puis il y a des difficultés nouvelles, l’intégration d’un standard, l’intégration d’un moteur de workflow inconnu, etc. Un projet n’est pas simplement une suite de story, mais aussi du FURPS (performance, sécurité, robustesse, etc.) . Voir le projet que sous l’angle du fonctionnel est la manière méthode pour avoir un produit de qualité médiocre et souvent jetable.
Dans un monde idéal, le client achète un produit avec une cible fonctionnelle sans même penser vouloir poser un planning de livraison final. La réalité est bien différente pour moi. Le client achète un produit avec une cible fonctionnelle, mais avec un planning de fin posé.
Initialement, pour calculer les charges, je fais appel à mon équipe. (Mon projet est découpé en « Use case », c’est mon côté technique et j’ajoute du FURPS.)
Je présente les différents cas d’utilisation que nous avons identifiés avec le client pour son projet, nous utilisons du planning poker, je n’interviens pas dans l’estimation, j’organise le timing de la réunion, je réponds à la question, je prends leur observation quand le use case est trop floue peur eux, en un mot je fluidifie la réunion.
Une fois les estimations réalisées, j’affecté ensuite d’un coefficient par type de profil (dev, intégrateur, documentaliste) . Ensuite, je regarde mon calendrier projet, si le projet passe sur des périodes de vacances importantes (tel que le mois de mai), je modifie mon coefficient pour cette période. J’ai encore pu le constater cette année, les périodes de mai avec des semaines de 3 jours génèrent un rendement très faible.
Toutefois, je ne fais pas de distinction par personne, mais par groupe de personnes. Je dirais que je fais du Scrum en mode alpinisme, le projet est comme une équipe en cordée. Tant que le dernier n’a pas fini d’avancer, nous l’aidons avant de continuer la suite…
La force d’agile, c’est que tout le monde participe au planning.
Je n’ai pas utilisé la vélocité et je ne vois pas son utilité (cf. mon précédent billet), mes estimations de projet, viennent de mon expérience, de la participation des équipes lors de la planification, d’être entourée de ScrumMaster avec une très bonne expérience du développement.
« Cela peut être important lorsqu’il faut synchroniser la sortie d’une release et des évènements marketing ».
Cette phrase me fait penser que le marketing n’est pas considéré dès le début dans la phase projet. Tous les éléments de l’entreprise sont le projet, de la facturation au marketing. L’équipe marketing est intégrée dès le début du projet avec ses « use case », comme la partie financière, ce sont des phases à part entière du projet.
« Je suis curieux de savoir dans quel domaine tu travailles, car il semble que dans ton cas avoir une vision à moyen terme n’est pas nécessaire ? »
Je travaille dans l’open Source, nous faisons soit du développement spécifique, soit du développement sur nos produits. Nous diffusons nos produits vers l’extérieur en complément de la livraison auprès du client. Nous développons une PKI (www.ejbca.org) depuis 2001 et nous allons mettre à disposition un nouveau projet qui se nomme LinShare.
Nous avons plusieurs visions, court terme pour les petits projets, moyen terme pour les projets plus importants et une vision à plus long terme pour nos projets Open Source. Nous avons aussi une vision particulière lorsque nos clients demandent des développements spécifiques sur nos projets c’est de leur faire changer d’avis pour le rendre générique et ainsi être dans la prochaines
L’Open Source à une culture importante du planning du release et du développement incrémentale, un peu moins de l’itération. Nous avons donc l’habitude de pratique « Agile »
« Comment sais-tu sais combien de “use cases” tu peux “caser” dans ta time-box »
Un « use case » possède sa propre charge, si tu as défini un sprint de 30 jours, tu prends tes « use case » prioritaire pour remplir tes premiers sprint. Par exemple, si j’ai un use case de 15 jours et un autre de 10 jours, j’ai une première itération de 25 jours.
Aucun « use case » n’a de longueur fixe, cela n’a pas de sens.
François, je suis de ton avis, le PO organise la réunion de planification, donne le rythme, présente les cas d’utilisation, fluidifie la réunion. Mais il n’estime jamais.
« Sans se vouloir être LA référence, Jeff Sutherland raconte régulièrement que la première question qu’il pose à un patron qui dit pratiquer l’agilité dans son entreprise est “Quelle est votre vélocité ?”. Et que si le patron ne sait pas répondre. »
Cela m’a bien fait rire 🙂 Honnêtement combien de patron pourrait répondre, ce n’est pas ce que j’attends de mon patron.
Bonjour Alexandre,
Désolé de me poser des questions sur la vélocité, mais c’est mon côté à me remettre en question 🙂
Je voulais connaitre votre avis sur l’apport de la vélocité par rapport à votre expérience.
Vous manquerait elle si elle n’était pas présente dans la méthode ?
Qu’elle alternative à la vélocité ?
Bon week-end à tous
Yannick