Commentaire d'un directeur d'établissement après le sprint 3 d'un gros projet : "bravo, la vélocité est au rendez-vous (ie, ça colle avec les estimations waterfall du projet pour l'atterrissage)" ! => autant que possible, ne pas afficher la vélocité en dehors de l'équipe car les parties-prenantes ne comprennent pas ce que c'est. Afficher la Business Value livrée doit normalement être bien plus intéressant pour les parties-prenantes. J'aime bien les provoquer en leur demandant quel est l'impact d'un durcissement de la DOD sur la vélocité ? Plus l'équipe devient rigoureuse, moins il y a de dette technique, mais plus la vélocité baisse. Alors, chefs, allez-vous engueuler une équipe qui durcit sa DOD ?
Merci JP, complètement d’accord. J’ajouterai deux cas d’utilisation de la vélocités : 1/ détecter ce que j’appelle la ShadowVelocity, c’est tout le travail qui est fait en heures supp pour rester « dans l’estimation », ou pendant un week-end pour finir le sprint avant la revue. Le Scrum Master doit se doter d’outils pour détecter ça et le faire ressortir pour expliquer que ce n’est pas une bonne façon de faire, j'ai écris un article là-dessus : medium.com/@cog_g/le-guide-de-la-shadow-velocity-pour-les-scrum-masters-ed4ce18fe8da 2/ visualiser la dette technique : en incluant ou pas la dette dans la vélocité, il faut absolument faire apparaître cette dette proche de l’affichage de la vélocité. Car l’important n’est pas tant la quantité de choses faites, mais aussi la quantité de valeurs produites pendant le sprint => medium.com/@cog_g/compter-la-dette-technique-dans-la-v%C3%A9locit%C3%A9-ou-pas-6111f4733282 On peut avoir une belle vélocité sans dents de scie mais qui n’apporte rien de valeur au produit.
Merci pour cette vidéo. Ça me rassure, je n'exploitais pas la vélocité car elle variait trop en fonction de la maintenance des applications en production. Je savais que ce temps perdu sur le projet n'étais pas "normale" même si c'est malheureusement la réalité des choses et que je ne pouvais pas blâmer l'équipe.C'est une perturbation extérieure qui reflète un problème plus haut. Cette notion est mal expliquée et du coup mal exploitée je pense par beaucoup. Elle s'avère être, mal utilisée, comme une source de stress à l'équipe, alors que c'est juste un outil pour du macro planning ou pour se rendre compte qu'il y a un problème qui perturbe l'équipe.
Personnellement je calcul la vélocité réalisé par ETP présent ce qui me permet de prendre des engagements aussi autour de grosse période de congés. Il faut gérer les congés mat, les vacances longues en septembre et ceux des vacances scolaires. Ce n’est pas une usine à gaz et ça m’est indispensable.
Avez-vous déjà essayé de préparer le Sprint en Sprint Planning sans cette information, juste en demandant à l'équipe si "ça passe" ou pas selon eux ? -- JP
Question, la vélocité permet de faire du macro. Cela veut dire qu'il faut définir l'effort des US afin de pouvoir voir à long terme. Cet effort est défini par, par exemple, le planning pocker. Est-ce que ce planning pocker se fait pendant la réunion de planning du sprint ?
Salut Xavier ! Et bien, par exemple si ton équipe utilises les Story Points, en fin d'itération on additionne les Story Points de tous les éléments terminés et cette somme c'est la vélocité de l'itération. Tout simplement. Si par exemple on a terminé un élément à 5, deux élément à 3 et un à 2, ça fait : 1*5 + 2*3 + 1*2 = 13 On ne compte bien *que ce qui est teminé*, tout ce qui est commencé mais pas terminé ne compte pas / compte pour zéro. Puis on fait ce calcule à chaque itération, et on peut alors calculer une moyenne sur plusieurs itérations, qui permettra de faire des projections de planification. Est-ce clair ainsi ? -- JP
Bonjour JP et merci pour cette vidéo. Nous sommes passé en SCRUM recemment sur certains de nos projets et expérimentons le suivi (et la prévision) à partir de la vélocité. Effectivement, utiliser une moyenne sur plusieurs sprints semble assez pertinent. Ne serait-ce que par rapport au transfert des users story non terminées qui peut introduire des variations importantes entre sprints. Cependant, utiliser une moyenne sur tous les sprints ne donne pas forcement une indication pertinente. Par exemple, les premiers sprints (surtout le premier) intègrent beaucoup de tâches de mise en place diverses (de l'environnement de travail, de l'organisation de l'équipe etc) et ne sont du coup pas très représentatives des sprints "de croisière" ou de fin. Dans nos projets nous commençons à tester l'utilisation d'une moyenne glissante sur les 2 ou 3 derniers sprints. Votre avis sur cette approche ?
Bonsoir l’équipe , j’aimerais savoir svp lorsqu’on parle d’un sprint d’une semaine … 1) Est-ce qu’il s’agit de 05 jours ouvrables ? 2) Est-ce que tous les événements et ateliers y-relatifs ( planning , sprint proprement dit , autres ateliers éventuels - spikes , refinement - , revue , retro ) seront calés dans cette time box ou alors cette time box concernera juste la partie développement des US par la Dev team ? Je pose cette question pour ne pas fausser le calcul de la vélocité et du burndown .
Salut ! Oui on parle de 5 jours ouvrables. Cela inclut TOUT le sprint, donc cela inclut bien tous les événements et ateliers. Du DEBUT à la FIN. Cela ne devrait pas fausser les calculs de vélocité et autres burndown car tout ce temps passé en événement et ateliers est plus ou moins proportionnel à la durée de l'itération ; on planifie deux fois moins de choses quand on passe de 2 semaines à 1 semaine ! Il y a aussi le fait que les événements et les ateliers sont AUSSI du travail et surtout pas du temps perdu -- sinon il faut arrêter ou les faire autrement ! As-tu déjà essayé le sprint d'une semaine ? -- JP
@@ScrumLife je crains de ne pouvoir faire tout ça en 5 jours . Okay, planning fera maxi 2 heures , on se jette immédiatement à l’eau , on bosse jusqu’à mercredi , l’équipe build l’incrément du sprint , on planifie la revue de sprint jeudi , et la rétro vendredi , ouais ça peut le faire , à condition que l’objectif soit très rationnel, que l’équipe soit vraiment autogérée pour éviter les réunions dont on peut se passer , que la vision produit soit claire , mais aussi le sprint goal , et qu’on passe moins de temps sur les refinements / spikes , ateliers . La seconde condition est que les parties prenantes soient dispo et qu’il n’y ait pas trop de hiérarchie / politique au sein de l’organisation , parfois il faut assez de temps pour informer et avoir les parties prenantes clés à la revue.
Bonjour SCRUMLIFE, tout d'abord merci pour vos bons conseils 👍✌️ Je reviens vers vous car en tant que PO j'ai une grosse dette technique qui nécessite un projet de cicd, de migration technique cloud et en même temps de datalake. Tout ceci bouffe énormément de bande passante pour travailler sur les fonctionnalités et le produit en lui même. Je gère bien mon projet et donc je planifie bien et arrive à remplir les objectifs fixés. Le souci c'est que j'ai un backlog long comme le bras avec des priorités en veux tu en voilà, mais quasiment plus de bande passante. Plusieurs fois nous avons demandé un renforcement technique pour augmenter cette bande passante et ainsi traiter plus de sujets. On sent bien que les utilisateurs se moquent complètement des migrations techniques, mais elles sont indispensables pour des raisons de support. On sent également bien les attentes sur le fonctionnel. J'utilise la méthode invest mais je voudrais savoir si vous n'aviez pas des astuces pour produire plus de valeur avec ma faible bande passante actuelle. J'ai mis en place des outils agiles etc pour fluidifier au max. Merci SCRUMLIFE
Hello ! Tout d'abord merci pour tes vidéos elles sont vraiment plaisantes à regarder ! Je voudrais revenir sur le fait d'avoir, lorsque l'on estime, une "fenêtre d'arrivée" et non une date d'arrivée. Je me suis toujours dit qu'au contraire il était important d'avoir une date d'arrivée pour justement se concentrer sur la réalisation des fonctionnalités ayant le plus de valeur et les prioriser en ajustant le backlog. Ainsi on pourra avoir une partie du produit livrée pour cette date donnée. Qu'en penses-tu ? Merci !
@@ScrumLife Justement l'incertitude des estimations et la variabilité de la vélocité fait qu'un risque existe même sur le fait de figer un périmètre minimal donc pourquoi calculer une fenêtre d'arrivée ? En fait je me dis que plus je vais figer mon périmètre, même minimal, moins je vais réussir à être agile, en théorie en tout cas. Enfin quoi qu'il en soit j'ai commencé la lecture de "Agile estimating and planning" donc je devrais avoir pas mal de réponses à mes questions :)
Bonjour Jean-Pierre, Je t'avoue que cette vidéo m'a un peu perdu. En effet, aujourd'hui j'utilise la vélocité + comme un moyen de savoir ce que m'on équipe peut embarquer pendant une itération ( Sprint) que pour anticiper ce qu'elle pourrait prendre dans le futur. Petite précision, nous fonctionnons en Safe. La pratique est elle différente? SI ce n'est pas le cas, comment faire pour bien prévoir lors du PI planning? Merci par avance pour ta réponse,
Bonjour, j'ai une question qui ne va pas vous plaire, mais j'aimerais bien une autre réponse que celle d'un normand : comment savoir combien de JH peut-on comptabiliser pour 1 ETP sur un sprint de 3 semaines sachant que la structure dans laquelle je suis exige des jours hommes et non des story points, sachant qu'il n'y a pas de jours de congés et sachant que le scrummaster n'est pas transparent et qu'il ne me transmet pas ses règles de calculs qu'il utilise pourtant pour me donner la capacité de l'équipe. Je dis qu'il n'est pas transparent car cela fait 7 fois que je lui demande le livrable (sa feuille excel lui permettant de calculer et qu'il utilise pour me donner sa capacité estimée en JH). N'ayant pas la visibilité suffisante et ayant le sentiment de me faire enfumer je pense que je vais volontairement surcharger les sprints pour vérifier la capa réelle en JH, quitte à rebaisser pas la suite, bref pour voir jusqu'ou je peux aller avant que ça grince des dents. L'idée n'est pas de les surcharger, mais juste ne ne pas me faire enfumer et travailler avec sérieux en bonne intelligence et sur le long terme avec un vrai enrichissement mutuel. Je regrette cette posture du scrummaster qui fait de la rétention d'information.
Bonjour Pierre-Yves, désolé de te répondre tard. Si j'ai bien compris, tu souhaites savoir comment on peut connaître la capacité réelle d'un ETP sur un sprint car la structure te demande cette information. J'ajoute de ce que j'ai compris que la réponse qui t'es donné ne te convient pas (à toi ou à la structure). Pour pouvoir te répondre en te donnant mon avis, il me manque des informations : à quoi cela va-t-il te servir de connaître cette capacité ? Ou, le cas échéant, à quoi cela va servir à la personne qui t'a demandé cette information ? -- Constantin
@@ScrumLife bonjour Constantin, merci beaucoup pour votre retour, c'est tout à fait ça, l'information va me servir à évaluer le nombre d'US à intégrer dans mes prochains sprints en fonction de la charge estimée également en JH et pour la gouvernance l'information va lui servir à valider le recrutement d'une personne ou le renforcement de l'équipe par des heures sup en évaluant la capacité de l'équipe sur plusieurs sprints (capacité donnée en jours JH mais que l'on pourrait très bien convertir en story point de complexité s'ils étaient un peu plus agile). Il y'a un manque de transparence côté MOE et je voudrais éviter également de les surcharger, ce que ne fait pas notre scrum qui a tendance à charger au max du max..
@Pierre-Yves SORDES merci pour cette précision. Tu écris "l'information va me servir à évaluer le nombre d'US à intégrer dans mes prochains sprints en fonction de la charge estimée", or, ce n'est pas ce qu'on attend comme fonctionnement d'une équipe agile. Pourquoi ? Car ce n'est pas du tout efficace, tout simplement. Ce qu'on attends d'un PO dans une équipe agile, c'est de prendre des décisions stratégiques et de transmettre un objectif au reste de l'équipe, c'est à dire le "POURQUOI". Ensuite, c'est aux experts (les dev par exemple), de décider ce qui doit être pris dans le sprint ou pas. Pas dans le but de "s'occuper", mais bel et bien pour atteindre l'objectif qui leur est donné et en lequel ils DOIVENT croire. Tu ne peux donc pas les surcharger, puisque c'est eux qui choisissent leur charge. C'est forcément pas simple de décrire tout ça dans un commentaire, je me suis donc permis de te préparer une liste de vidéo à voir ou revoir qui expliquent tout ça et comment se crée la dynamique dans une équipe vraiment efficace : PO : ua-cam.com/video/PgniBA8HPBk/v-deo.html DEV : ua-cam.com/video/Ztm9FipQkd0/v-deo.html PO "Produit" : ua-cam.com/video/ygMjk1DR2AQ/v-deo.html Sprint Planning : ua-cam.com/video/dqABiJ4qj_Y/v-deo.html Backlog : ua-cam.com/video/4BvjxGEJ5v0/v-deo.html Sprint Backlog : ua-cam.com/video/oqCCbelijLI/v-deo.html Ces vidéos sont plutôt orientées Scrum, mais pas que, ce qui y est décrit est valable quelque soit votre approche. Dans ces vidéos, tu verras j'espère qu'en fait, ça n'a aucune importance le nombre d'US faites ou à faire. Le nombre d'US ne garanti en rien l'efficacité de l'équipe, car on peut faire beaucoup de choses de piètres qualité ou qui n'étaient pas à faire ! Au contraire, moins l'équipe fait de choses pour atteindre un objectif, plus le produit sera simple à maintenir et donc, moins couteux. En tant que PO, essaye plutôt de t'assurer que ce sur quoi travail l'équipe à vraiment de la valeur, que tu comprends cette valeur et que le reste de l'équipe aussi. À très bientôt j'espère ! -- Constantin PS : Utiliser des story points n'a JAMAIS rendu une équipe "agile" à ma connaissance.
Merci beaucoup Constantin, d'accord tout est clair, il faut présenter l'objectif en tant que PO et charge aux dev de sélectionner eux memes leurs US (je fais quasiment cela). Sauf que notre SM LUI insiste pour que je procède au choix et à la planification dans les sprints. Je le fais systématiquement collégialement avec les DEV, donc finalement je fais un peu ce que tu décris en les faisant largement participer et en faisant le choix avec eux sans leur imposer je les guide et les challenge simplement et eux m'apportent leur expertise. Le vrai problème c'est que c'est le SM qui charge le sprint sans mon accord (il n'est pas très ''agile'') même lorsque je lui dit. Alors pour le contrecarrer le met certaines us en trop en nicetohave en demandant au dev de ne pas les traiter comme ça M. SM est content, il a rempli son sprint... Mais j'en reviens a la notion de Jour H. Ce que tu dis c'est en gros peu importe le nombre de jour homme du moment que les dev choisissent leurs US. Merci pour les vidéos, c'est globalement ce que je fais d'après ce que tu décrits mais je vais les regarder à nouveau. Le seul pb reste le chiffrage initial donné par LA MOE, car celui-ci est transmis par le SCRUM qui s'impose trop sur les DEV (équipe offshore)
Hello. je comprend pas trop la dernière partie de la vidéo. Le SM arrive inquiet en retro car l'équipe a une vélocité en dents de scie. L''équipe de dev peut être surprise, car aux différents sprint planning elle s'est engagée à prendre des US découpées en tache technique et chiffrée en jour sans regarder le nombre de point prévus des US. Mais dès le sprint planning on voyait déjà que la vélocité cible du sprint, était très inférieur/supérieur la vélocité du sprint précédent. j'ai l'impression que sur la fin de la vidéo il y a mélange entre vélocité des sprints, et engagement non atteint.
Merci, c'est un point de vue intéressant ! En effet, il y a plusieurs manières d'interpréter la situation fictive que je met en scène. Peut-être que dans cet exemple le Scrum Master pousse un peu trop loin ses hypothèses, et devrait se contenter de mettre sur la table la question de la vélocité en dents de scies.
Découvrez toute la communauté Scrum Life ! 👉 sl.run/wnRgK9
Commentaire d'un directeur d'établissement après le sprint 3 d'un gros projet : "bravo, la vélocité est au rendez-vous (ie, ça colle avec les estimations waterfall du projet pour l'atterrissage)" ! => autant que possible, ne pas afficher la vélocité en dehors de l'équipe car les parties-prenantes ne comprennent pas ce que c'est. Afficher la Business Value livrée doit normalement être bien plus intéressant pour les parties-prenantes.
J'aime bien les provoquer en leur demandant quel est l'impact d'un durcissement de la DOD sur la vélocité ? Plus l'équipe devient rigoureuse, moins il y a de dette technique, mais plus la vélocité baisse. Alors, chefs, allez-vous engueuler une équipe qui durcit sa DOD ?
Je te remercies pour tes vidéos qui utilisent un très bon format.
Merci JP, complètement d’accord. J’ajouterai deux cas d’utilisation de la vélocités :
1/ détecter ce que j’appelle la ShadowVelocity, c’est tout le travail qui est fait en heures supp pour rester « dans l’estimation », ou pendant un week-end pour finir le sprint avant la revue. Le Scrum Master doit se doter d’outils pour détecter ça et le faire ressortir pour expliquer que ce n’est pas une bonne façon de faire, j'ai écris un article là-dessus : medium.com/@cog_g/le-guide-de-la-shadow-velocity-pour-les-scrum-masters-ed4ce18fe8da
2/ visualiser la dette technique : en incluant ou pas la dette dans la vélocité, il faut absolument faire apparaître cette dette proche de l’affichage de la vélocité. Car l’important n’est pas tant la quantité de choses faites, mais aussi la quantité de valeurs produites pendant le sprint => medium.com/@cog_g/compter-la-dette-technique-dans-la-v%C3%A9locit%C3%A9-ou-pas-6111f4733282
On peut avoir une belle vélocité sans dents de scie mais qui n’apporte rien de valeur au produit.
Merci pour cette vidéo. Ça me rassure, je n'exploitais pas la vélocité car elle variait trop en fonction de la maintenance des applications en production. Je savais que ce temps perdu sur le projet n'étais pas "normale" même si c'est malheureusement la réalité des choses et que je ne pouvais pas blâmer l'équipe.C'est une perturbation extérieure qui reflète un problème plus haut.
Cette notion est mal expliquée et du coup mal exploitée je pense par beaucoup. Elle s'avère être, mal utilisée, comme une source de stress à l'équipe, alors que c'est juste un outil pour du macro planning ou pour se rendre compte qu'il y a un problème qui perturbe l'équipe.
Personnellement je calcul la vélocité réalisé par ETP présent ce qui me permet de prendre des engagements aussi autour de grosse période de congés. Il faut gérer les congés mat, les vacances longues en septembre et ceux des vacances scolaires. Ce n’est pas une usine à gaz et ça m’est indispensable.
Nous utilisons la vélocité pour savoir combien de travail prendre pour les sprints prochains
Avez-vous déjà essayé de préparer le Sprint en Sprint Planning sans cette information, juste en demandant à l'équipe si "ça passe" ou pas selon eux ?
-- JP
Question, la vélocité permet de faire du macro. Cela veut dire qu'il faut définir l'effort des US afin de pouvoir voir à long terme. Cet effort est défini par, par exemple, le planning pocker. Est-ce que ce planning pocker se fait pendant la réunion de planning du sprint ?
Oui, le Planning Poker se fait pendant le Sprint Planning
MErci. Je n'ai pas compris comment calculer la vélocité
Salut Xavier !
Et bien, par exemple si ton équipe utilises les Story Points, en fin d'itération on additionne les Story Points de tous les éléments terminés et cette somme c'est la vélocité de l'itération. Tout simplement.
Si par exemple on a terminé un élément à 5, deux élément à 3 et un à 2, ça fait : 1*5 + 2*3 + 1*2 = 13
On ne compte bien *que ce qui est teminé*, tout ce qui est commencé mais pas terminé ne compte pas / compte pour zéro.
Puis on fait ce calcule à chaque itération, et on peut alors calculer une moyenne sur plusieurs itérations, qui permettra de faire des projections de planification.
Est-ce clair ainsi ?
-- JP
Bonjour JP et merci pour cette vidéo.
Nous sommes passé en SCRUM recemment sur certains de nos projets et expérimentons le suivi (et la prévision) à partir de la vélocité.
Effectivement, utiliser une moyenne sur plusieurs sprints semble assez pertinent. Ne serait-ce que par rapport au transfert des users story non terminées qui peut introduire des variations importantes entre sprints.
Cependant, utiliser une moyenne sur tous les sprints ne donne pas forcement une indication pertinente.
Par exemple, les premiers sprints (surtout le premier) intègrent beaucoup de tâches de mise en place diverses (de l'environnement de travail, de l'organisation de l'équipe etc) et ne sont du coup pas très représentatives des sprints "de croisière" ou de fin.
Dans nos projets nous commençons à tester l'utilisation d'une moyenne glissante sur les 2 ou 3 derniers sprints.
Votre avis sur cette approche ?
Bonjour à tous, la moyenne glissante est plus pertinente, ça reflète plus la réalité de l'avancement et l'impact des changements
Bonsoir l’équipe , j’aimerais savoir svp lorsqu’on parle d’un sprint d’une semaine …
1) Est-ce qu’il s’agit de 05 jours ouvrables ?
2) Est-ce que tous les événements et ateliers y-relatifs ( planning , sprint proprement dit , autres ateliers éventuels - spikes , refinement - , revue , retro ) seront calés dans cette time box ou alors cette time box concernera juste la partie développement des US par la Dev team ? Je pose cette question pour ne pas fausser le calcul de la vélocité et du burndown .
Salut !
Oui on parle de 5 jours ouvrables.
Cela inclut TOUT le sprint, donc cela inclut bien tous les événements et ateliers. Du DEBUT à la FIN.
Cela ne devrait pas fausser les calculs de vélocité et autres burndown car tout ce temps passé en événement et ateliers est plus ou moins proportionnel à la durée de l'itération ; on planifie deux fois moins de choses quand on passe de 2 semaines à 1 semaine ! Il y a aussi le fait que les événements et les ateliers sont AUSSI du travail et surtout pas du temps perdu -- sinon il faut arrêter ou les faire autrement !
As-tu déjà essayé le sprint d'une semaine ?
-- JP
@@ScrumLife je crains de ne pouvoir faire tout ça en 5 jours . Okay, planning fera maxi 2 heures , on se jette immédiatement à l’eau , on bosse jusqu’à mercredi , l’équipe build l’incrément du sprint , on planifie la revue de sprint jeudi , et la rétro vendredi , ouais ça peut le faire , à condition que l’objectif soit très rationnel, que l’équipe soit vraiment autogérée pour éviter les réunions dont on peut se passer , que la vision produit soit claire , mais aussi le sprint goal , et qu’on passe moins de temps sur les refinements / spikes , ateliers . La seconde condition est que les parties prenantes soient dispo et qu’il n’y ait pas trop de hiérarchie / politique au sein de l’organisation , parfois il faut assez de temps pour informer et avoir les parties prenantes clés à la revue.
Bonjour SCRUMLIFE, tout d'abord merci pour vos bons conseils 👍✌️
Je reviens vers vous car en tant que PO j'ai une grosse dette technique qui nécessite un projet de cicd, de migration technique cloud et en même temps de datalake. Tout ceci bouffe énormément de bande passante pour travailler sur les fonctionnalités et le produit en lui même.
Je gère bien mon projet et donc je planifie bien et arrive à remplir les objectifs fixés. Le souci c'est que j'ai un backlog long comme le bras avec des priorités en veux tu en voilà, mais quasiment plus de bande passante. Plusieurs fois nous avons demandé un renforcement technique pour augmenter cette bande passante et ainsi traiter plus de sujets. On sent bien que les utilisateurs se moquent complètement des migrations techniques, mais elles sont indispensables pour des raisons de support. On sent également bien les attentes sur le fonctionnel. J'utilise la méthode invest mais je voudrais savoir si vous n'aviez pas des astuces pour produire plus de valeur avec ma faible bande passante actuelle. J'ai mis en place des outils agiles etc pour fluidifier au max.
Merci SCRUMLIFE
Hello ! Tout d'abord merci pour tes vidéos elles sont vraiment plaisantes à regarder !
Je voudrais revenir sur le fait d'avoir, lorsque l'on estime, une "fenêtre d'arrivée" et non une date d'arrivée. Je me suis toujours dit qu'au contraire il était important d'avoir une date d'arrivée pour justement se concentrer sur la réalisation des fonctionnalités ayant le plus de valeur et les prioriser en ajustant le backlog. Ainsi on pourra avoir une partie du produit livrée pour cette date donnée. Qu'en penses-tu ?
Merci !
@@ScrumLife Justement l'incertitude des estimations et la variabilité de la vélocité fait qu'un risque existe même sur le fait de figer un périmètre minimal donc pourquoi calculer une fenêtre d'arrivée ? En fait je me dis que plus je vais figer mon périmètre, même minimal, moins je vais réussir à être agile, en théorie en tout cas. Enfin quoi qu'il en soit j'ai commencé la lecture de "Agile estimating and planning" donc je devrais avoir pas mal de réponses à mes questions :)
Bonjour Jean-Pierre,
Je t'avoue que cette vidéo m'a un peu perdu.
En effet, aujourd'hui j'utilise la vélocité + comme un moyen de savoir ce que m'on équipe peut embarquer pendant une itération ( Sprint) que pour anticiper ce qu'elle pourrait prendre dans le futur. Petite précision, nous fonctionnons en Safe.
La pratique est elle différente? SI ce n'est pas le cas, comment faire pour bien prévoir lors du PI planning?
Merci par avance pour ta réponse,
Bonjour, j'ai une question qui ne va pas vous plaire, mais j'aimerais bien une autre réponse que celle d'un normand : comment savoir combien de JH peut-on comptabiliser pour 1 ETP sur un sprint de 3 semaines sachant que la structure dans laquelle je suis exige des jours hommes et non des story points, sachant qu'il n'y a pas de jours de congés et sachant que le scrummaster n'est pas transparent et qu'il ne me transmet pas ses règles de calculs qu'il utilise pourtant pour me donner la capacité de l'équipe.
Je dis qu'il n'est pas transparent car cela fait 7 fois que je lui demande le livrable (sa feuille excel lui permettant de calculer et qu'il utilise pour me donner sa capacité estimée en JH). N'ayant pas la visibilité suffisante et ayant le sentiment de me faire enfumer je pense que je vais volontairement surcharger les sprints pour vérifier la capa réelle en JH, quitte à rebaisser pas la suite, bref pour voir jusqu'ou je peux aller avant que ça grince des dents. L'idée n'est pas de les surcharger, mais juste ne ne pas me faire enfumer et travailler avec sérieux en bonne intelligence et sur le long terme avec un vrai enrichissement mutuel. Je regrette cette posture du scrummaster qui fait de la rétention d'information.
Bonjour Pierre-Yves, désolé de te répondre tard. Si j'ai bien compris, tu souhaites savoir comment on peut connaître la capacité réelle d'un ETP sur un sprint car la structure te demande cette information.
J'ajoute de ce que j'ai compris que la réponse qui t'es donné ne te convient pas (à toi ou à la structure).
Pour pouvoir te répondre en te donnant mon avis, il me manque des informations : à quoi cela va-t-il te servir de connaître cette capacité ? Ou, le cas échéant, à quoi cela va servir à la personne qui t'a demandé cette information ?
-- Constantin
@@ScrumLife bonjour Constantin, merci beaucoup pour votre retour, c'est tout à fait ça, l'information va me servir à évaluer le nombre d'US à intégrer dans mes prochains sprints en fonction de la charge estimée également en JH et pour la gouvernance l'information va lui servir à valider le recrutement d'une personne ou le renforcement de l'équipe par des heures sup en évaluant la capacité de l'équipe sur plusieurs sprints (capacité donnée en jours JH mais que l'on pourrait très bien convertir en story point de complexité s'ils étaient un peu plus agile). Il y'a un manque de transparence côté MOE et je voudrais éviter également de les surcharger, ce que ne fait pas notre scrum qui a tendance à charger au max du max..
@Pierre-Yves SORDES merci pour cette précision.
Tu écris "l'information va me servir à évaluer le nombre d'US à intégrer dans mes prochains sprints en fonction de la charge estimée", or, ce n'est pas ce qu'on attend comme fonctionnement d'une équipe agile. Pourquoi ? Car ce n'est pas du tout efficace, tout simplement.
Ce qu'on attends d'un PO dans une équipe agile, c'est de prendre des décisions stratégiques et de transmettre un objectif au reste de l'équipe, c'est à dire le "POURQUOI".
Ensuite, c'est aux experts (les dev par exemple), de décider ce qui doit être pris dans le sprint ou pas. Pas dans le but de "s'occuper", mais bel et bien pour atteindre l'objectif qui leur est donné et en lequel ils DOIVENT croire. Tu ne peux donc pas les surcharger, puisque c'est eux qui choisissent leur charge.
C'est forcément pas simple de décrire tout ça dans un commentaire, je me suis donc permis de te préparer une liste de vidéo à voir ou revoir qui expliquent tout ça et comment se crée la dynamique dans une équipe vraiment efficace :
PO : ua-cam.com/video/PgniBA8HPBk/v-deo.html
DEV : ua-cam.com/video/Ztm9FipQkd0/v-deo.html
PO "Produit" : ua-cam.com/video/ygMjk1DR2AQ/v-deo.html
Sprint Planning : ua-cam.com/video/dqABiJ4qj_Y/v-deo.html
Backlog : ua-cam.com/video/4BvjxGEJ5v0/v-deo.html
Sprint Backlog : ua-cam.com/video/oqCCbelijLI/v-deo.html
Ces vidéos sont plutôt orientées Scrum, mais pas que, ce qui y est décrit est valable quelque soit votre approche.
Dans ces vidéos, tu verras j'espère qu'en fait, ça n'a aucune importance le nombre d'US faites ou à faire. Le nombre d'US ne garanti en rien l'efficacité de l'équipe, car on peut faire beaucoup de choses de piètres qualité ou qui n'étaient pas à faire ! Au contraire, moins l'équipe fait de choses pour atteindre un objectif, plus le produit sera simple à maintenir et donc, moins couteux.
En tant que PO, essaye plutôt de t'assurer que ce sur quoi travail l'équipe à vraiment de la valeur, que tu comprends cette valeur et que le reste de l'équipe aussi.
À très bientôt j'espère !
-- Constantin
PS : Utiliser des story points n'a JAMAIS rendu une équipe "agile" à ma connaissance.
Merci beaucoup Constantin, d'accord tout est clair, il faut présenter l'objectif en tant que PO et charge aux dev de sélectionner eux memes leurs US (je fais quasiment cela). Sauf que notre SM LUI insiste pour que je procède au choix et à la planification dans les sprints. Je le fais systématiquement collégialement avec les DEV, donc finalement je fais un peu ce que tu décris en les faisant largement participer et en faisant le choix avec eux sans leur imposer je les guide et les challenge simplement et eux m'apportent leur expertise. Le vrai problème c'est que c'est le SM qui charge le sprint sans mon accord (il n'est pas très ''agile'') même lorsque je lui dit. Alors pour le contrecarrer le met certaines us en trop en nicetohave en demandant au dev de ne pas les traiter comme ça M. SM est content, il a rempli son sprint... Mais j'en reviens a la notion de Jour H. Ce que tu dis c'est en gros peu importe le nombre de jour homme du moment que les dev choisissent leurs US.
Merci pour les vidéos, c'est globalement ce que je fais d'après ce que tu décrits mais je vais les regarder à nouveau.
Le seul pb reste le chiffrage initial donné par LA MOE, car celui-ci est transmis par le SCRUM qui s'impose trop sur les DEV (équipe offshore)
Hello. je comprend pas trop la dernière partie de la vidéo.
Le SM arrive inquiet en retro car l'équipe a une vélocité en dents de scie.
L''équipe de dev peut être surprise, car aux différents sprint planning elle s'est engagée à prendre des US découpées en tache technique et chiffrée en jour sans regarder le nombre de point prévus des US.
Mais dès le sprint planning on voyait déjà que la vélocité cible du sprint, était très inférieur/supérieur la vélocité du sprint précédent.
j'ai l'impression que sur la fin de la vidéo il y a mélange entre vélocité des sprints, et engagement non atteint.
Merci, c'est un point de vue intéressant ! En effet, il y a plusieurs manières d'interpréter la situation fictive que je met en scène. Peut-être que dans cet exemple le Scrum Master pousse un peu trop loin ses hypothèses, et devrait se contenter de mettre sur la table la question de la vélocité en dents de scies.
merci ;)
Très intéressant merci
Merci et avec plaisir !
Qu'est-ce que tu retiens le plus de cette vidéo ?
-- JP
@@ScrumLife La dérive de la vélocité vers des indicateurs de performance, ou encore la nécessité de bien finir le travail même s'il a été sous-estimé
Top ! Merci !
Est-ce que ça résonne avec ta propre expérience ?
-- JP