Comment bien utiliser la vélocité - Scrum Life 19

Summary

Le script traite de l'utilisation de la vélocité dans les projets Agile, soulignant son importance pour la planification future et l'estimation de la durée de réalisation des projets. Il met en garde contre les erreurs courantes comme la fixation sur la vélocité actuelle au détriment de l'analyse des moyennes historiques, et l'utilisation abusive pour des engagements précis lors des Sprint Planning. Le script recommande de considérer la vélocité comme un outil d'estimation basé sur l'historique pour une meilleure prévisibilité, plutôt que comme un indicateur de performance immédiate.

Takeaways

• 📏 La vélocité est une mesure de la quantité de travail que l'équipe peut réaliser pendant une itération.
• ⏳ Utilisez la moyenne de la vélocité sur plusieurs itérations pour faire des projections fiables sur l'avenir.
• 🚫 Ne basez pas la planification d'une itération sur une seule mesure de vélocité élevée ou basse.
• 🔢 La vélocité moyenne devrait être calculée sur au moins les 8 dernières itérations pour être significative.
• 📉 Une variation importante de la vélocité peut indiquer des problèmes systémiques ou une gestion de la charge de travail inadéquate.
• 📚 Il est recommandé de lire 'Agile Estimating and Planning' de Mike Cohn pour une compréhension approfondie de la planification agile.
• 🛠️ La vélocité est un outil d'abstraction qui ne doit pas être utilisé pour la planification détaillée au sein d'une itération.
• 👥 L'équipe Scrum est multidisciplinaire et les membres ne sont pas interchangeables, ce qui est pris en compte par la notion de vélocité.
• 🚫 La vélocité ne devrait pas être utilisée comme un indicateur de performance ou de réussite pour un Scrum Master.
• 🔄 Des fluctuations dans la vélocité peuvent être dues à de nombreux facteurs tels que le changement de taille de l'équipe, des compétences variées ou des technologies nouvelles.
• 🔄 Une courbe de vélocité qui varie beaucoup peut être un signe de prévisibilité faible, ce qui est un problème à aborder.

Q & A

Qu'est-ce que la vélocité dans le contexte d'une équipe Agile?

La vélocité est une mesure de la quantité de travail que l'équipe peut réaliser pendant une itération, et elle est utilisée pour faire des projections sur l'avenir et estimer les délais de fin de projet.

Pourquoi est-il important de considérer la vélocité comme une moyenne plutôt que comme un nombre unique pour une itération donnée?

La vélocité comme moyenne permet de tenir compte de la variabilité des performances de l'équipe sur plusieurs itérations, offrant ainsi un indicateur plus fiable pour la planification future.

Quels facteurs peuvent affecter la vélocité d'une équipe Agile?

La taille de l'équipe, les compétences des membres, les technologies utilisées, le type et la complexité des user stories, ainsi que les contraintes externes et les interactions avec d'autres équipes peuvent tous affecter la vélocité.

Comment la vélocité est-elle utilisée pour estimer la fin d'un projet ou d'une feature?

En divisant le nombre de points restants à réaliser par la vélocité moyenne de l'équipe, on peut estimer le nombre d'itérations nécessaires pour achever le projet ou la feature.

Pourquoi ne pas s'engager sur une quantité de travail basée uniquement sur la vélocité lors de la planification d'un sprint?

Parce que la vélocité est un outil d'estimation et de planification, et non un engagement. L'équipe doit s'engager sur une quantité de travail réaliste en fonction de l'analyse concrète des tâches et de la charge de travail prévue pour le sprint.

Quels sont les risques de mal utiliser la vélocité en tant qu'indicateur de performance?

Considérer la vélocité comme un indicateur de performance unique peut conduire à des conclusions erronées sur la capacité et l'efficacité de l'équipe, car elle ne tient pas compte des facteurs contextuels et des variations normales au cours du temps.

Que signifie une 'fenêtre d'arrivée' dans le contexte de la planification Agile?

Une 'fenêtre d'arrivée' est une plage de dates potentielles pendant laquelle un projet ou une feature pourrait être fini, en tenant compte des incertitudes et de la variabilité des performances passées de l'équipe.

Pourquoi la vélocité d'une équipe Agile ne devrait pas être utilisée pour comparer les performances entre équipes?

Parce que chaque équipe a des contextes, des compétences et des challenges uniques qui rendent les comparaisons de vélocité infondées et potentiellement démotivantes.

Quels sont les signes qu'une équipe Agile est prévisible et stable en termes de performance?

Une équipe est prévisible et stable si sa vélocité moyenne reste constante ou suit une tendance lisse, sans présenter de fluctuations importantes ou de 'dents de scie' qui indiqueraient des problèmes systémiques ou de gestion.

Quels sont les effets pervers que peut-on observer si les développeurs travaillent plus vite que prévu et utilisent le temps libre pour créer de la 'dette technique'?

Cela peut entraîner une qualité de travail réduite, une surcharge de travail future et un manque de prioritisation des tâches les plus importantes, car l'équipe se concentre sur de la 'dette technique' plutôt que sur les besoins actuels et à venir.

Outlines

00:00

📈 La Vélocité dans l'Agilité

Le paragraphe 1 explique la notion de vélocité dans le cadre de la gestion de projet agile. La vélocité est présentée comme une mesure de la quantité de travail que l'équipe peut réaliser lors d'une itération. Elle permet de faire des projections sur l'avenir, comme la fin d'un projet ou d'une fonctionnalité. L'importance de considérer la vélocité comme une moyenne sur plusieurs itérations est soulignée, plutôt que de se baser sur une seule itération. Le script met en scène un échange entre un manager et un Scrum Master qui clarifie l'utilisation correcte de la vélocité pour planifier et éviter les erreurs de planification. Le Scrum Master insiste sur le fait que la vélocité est un outil d'aide à la planification et doit être utilisée avec un historique suffisant pour être fiable. Il évoque également le livre 'Agile Estimating and Planning' de Mike Cohn pour approfondir la compréhension de la planification agile.

05:00

🚫 Comment ne pas utiliser la Vélocité

Le paragraphe 2 traite des erreurs courantes liées à l'utilisation de la vélocité. Il met en garde contre l'utilisation de la vélocité comme un outil de pression ou de commitment pour l'équipe. Le texte souligne que la vélocité ne devrait pas être utilisée pour forcer l'équipe à prendre un volume de travail non réaliste. Il est également question de la nature multidisciplinaire de l'équipe Scrum et de la complexité de la tâche qui rend la prévision exacte difficile. Le paragraphe critique l'idée de s'engager sur une base de points sans considérer la réalité du travail et la compétence de l'équipe. Il appelle à une planification plus souple et à une meilleure compréhension des capacités de l'équipe, plutôt que de se baser strictement sur des chiffres.

Keywords

💡Vélocité

La vélocité est une mesure de la quantité de travail que l'équipe peut réaliser dans une itération donnée. Elle est cruciale pour la planification agile, permettant de faire des projections sur l'avenir et d'estimer quand un projet ou une fonctionnalité sera terminé. Dans le script, l'importance de la vélocité est soulignée comme outil de planification, mais aussi mis en garde contre son utilisation abusive pour engager des objectifs de travail.

💡Itération

Une itération est un intervalle de temps défini dans le cadre d'un processus agile, comme Scrum, où l'équipe travaille sur une série de tâches pour réaliser des objectifs. Le script mentionne l'utilisation de la vélocité pour estimer la fin des projets ou des fonctionnalités au cours des différentes itérations.

💡Moyenne

Dans le contexte du script, la moyenne de la vélocité est utilisée pour obtenir une estimation fiable et prévisible du travail de l'équipe. Il est recommandé de calculer la moyenne sur plusieurs itérations, idéalement les 8 dernières, pour éviter les fluctuations et obtenir une indication plus stable de la performance de l'équipe.

💡Planification agile

La planification agile est une méthode de gestion de projet qui permet de s'adapter rapidement aux changements et de réagir de manière flexible. Le script discute de l'utilisation de la vélocité comme outil de planification agile, en se basant sur l'historique pour prévoir l'avenir.

💡Burn Down Chart

Le Burn Down Chart est un outil visuel utilisé dans les méthodes agiles pour montrer la progression du travail effectué par rapport au temps. Dans le script, il est mentionné comme un moyen d'ajuster le plan en cours d'itération si le travail prend plus ou moins de temps que prévu.

💡Definition of Done

La 'Definition of Done' est un ensemble d'acceptations communes qui détermine quand un élément de travail est considéré comme terminé. Le script insiste sur l'importance de respecter cette définition, que le travail soit effectué dans les temps impartis ou non.

💡Multi-disciplinarité

L'équipe Scrum est décrite comme multi-disciplinaire, ce qui signifie qu'elle regroupe divers types de compétences et d'expertises. Dans le script, cela est utilisé pour illustrer la complexité de la planification et de l'estimation du travail, car chaque membre de l'équipe apporte des compétences uniques qui ne sont pas directement comparables.

💡Engagement

L'engagement dans le script se réfère à la décision de l'équipe de la quantité de travail qu'elle va prendre pour une itération. Il est souligné que l'équipe doit s'engager sur un travail réaliste et potentiellement challengeant, plutôt que de se baser uniquement sur la vélocité passée.

💡Prédictibilité

La prédictibilité est la capacité de l'équipe à fournir des estimations de travail fiables et à respecter les délais. Le script mentionne que plus l'équipe a de données historiques de vélocité, plus elle est prévisible et moins la fenêtre d'arrivée fluctue.

💡Techno

Dans le script, 'techno' fait référence aux technologies utilisées dans le développement. L'apprentissage et la maîtrise des nouvelles technologies sont mentionnés comme facteurs pouvant affecter la vélocité de l'équipe, car cela peut nécessiter un temps d'adaptation et d'apprentissage.

💡Détails de la tâche

Les 'détails de la tâche' sont l'ensemble des sous-tâches et des actions spécifiques requises pour réaliser une 'User Story' ou une fonctionnalité. Le script discute de l'importance de ne pas se concentrer sur les points ou la vélocité, mais plutôt sur la planification et la réalisation des tâches techniques réelles.

Highlights

La vélocité est la mesure de la quantité de travail que l'équipe accomplit pendant une itération.

Utiliser la vélocité pour faire des projections sur l'avenir et estimer la fin des projets ou des features.

La vélocité pour la planification doit être une moyenne sur plusieurs itérations pour être fiable.

Il est important de ne pas utiliser la vélocité d'une itération unique pour planifier mais plutôt une moyenne sur 8 itérations.

Le manager doit comprendre que la vélocité n'est pas un chiffre fixe mais une moyenne qui fluctue.

La vélocité moyenne doit être utilisée pour estimer le temps restant avant la fin d'un projet.

La vélocité n'est pas un outil pour s'engager sur une quantité de travail spécifique mais pour planifier.

L'équipe doit s'engager sur une quantité de travail réaliste et légèrement challengeante au Sprint Planning.

La vélocité est un outil abstrait qui ne doit pas être utilisé pour une planification détaillée.

L'équipe Scrum est multi-disciplinaire et les membres ne sont pas interchangeables, ce qui est pris en compte par la vélocité.

La vélocité ne doit pas être utilisée pour forcer l'équipe à prendre un certain nombre de points lors du Sprint Planning.

Il est important de ne pas ajuster la vélocité en fonction de la présence ou de l'absence d'équipes.

La vélocité ne doit pas être utilisée pour créer de la dette technique ou pour faire plus de travail que prévu.

Les développeurs ne doivent pas s'inquiéter des points pendant l'itération mais se concentrer sur la qualité du travail.

La vélocité n'est pas un indicateur de performance mais un outil pour la planification agile.

La comparaison de la vélocité entre équipes ou la même équipe à différents moments n'a pas de sens.

La stabilité de la vélocité est plus importante que son amélioration continue, car elle indique la prédictibilité de l'équipe.

Une vélocité en dents de scie peut être un signe de problèmes systémiques ou de mauvaise gestion de l'engagement de l'équipe.

La rétrovision sur la vélocité doit se concentrer sur la stabilité et la prédictibilité plutôt que sur une augmentation continue.

Transcripts

Aujourd'hui on va parler de la vélocité,

De comment on l'utilise,

Et surtout de comment on ne 'utilise pas !

(tambours)

La vélocité c'est la mesure de la quantité de travail

Qu'arrive à sortir l'équipe pendant une itération.

Et donc ça va nous permettre de faire des projections sur l'avenir,

De voir quand est ce que par exemple le projet sera fini,

Lorsqu'il atterrira, ou à plus petite échelle

Lorsqu'une feature donnée, un epic, un gros morceau sera fini.

(tambours)

Alors, très important :

La vélocité, celle qu'on va utiliser pour faire des planifications,

Ce doit être une moyenne !

Idéalement, si on a suffisamment d'historique,

Sur les 8 dernières itérations.

Pour avoir un indicateur fiable,

Qui va pouvoir servir à quelque chose.

Manager : Elle a produit combien, là, l'équipe ? 40 ???

Manager : Allez c'est bon ! Il reste 200 à faire,

Manager : 40 tac-tac ça nous fait 5 !

Manager : 5 itération c'est plié !

Manager : Super ! Vous êtes les meilleurs les gars !

Scrum Master : Oh non non non, attendez patron !

Scrum Master : Vous n'avez pas compris comment ça marche !

Scrum Master : Je vous explique : on fait la moyenne

Scrum Master : Sur plusieurs itérations !

Scrum Master : Parce que là, elle a fait 40,

Scrum Master : Mais celle d'avant elle a fait 5 !

Scrum Master : Là, en moyenne, on n'est pas à 40,

Scrum Master : On est plus à 20-25...

Scrum Master : Peut-être 28, là, avec le 40. Pas plus !

C'est comme ça que ça marche !

On prend le nombre de points qui restent à fournir,

200 points par exemple,

On le divise par la vélocité moyenne

-- Je précise bien : moyenne ! --

Donc là par exemple 28.

Voilà, on fait le calcul ça nous fait un peu plus de 7,

Donc 7 itérations,

Donc on va dire que dans huit itérations ça devrait être fait,

Ca devrait être fini.

(tambours)

Et en fait, et bien...

J'ai rien d'autre à dire sur la vélocité !

Par contre, on peut parler de comment ne PAS utiliser la vélocité !

Donc je rappelle à nouveau que c'est un outil

Pour faire de la planification au sens agile,

C'est à dire : on regarde comment ça s'est passé dans le passé,

Et on suppose que ça se passera comme ça dans l'avenir.

Donc, si on n'a pas d'historique,

Encore une fois si on n'a que quelques itérations,

Alors on n'a qu'assez peu de certitudes.

Sur ce sujet je vous recommande de lire par exemple

"Agile Estimating and Planning" de Mike Cohn,

Qui est un excellent livre sur le sujet :

Il fait le tour de la question de manière assez complète et très bien faite.

Et il explique justement qu'on n'a pas une date d'arrivée,

On a une date potentielle mais surtout une fenêtre d'arrivée.

C'est à dire : si ça se passe bien, si ça se passe moins bien.

Et cette fenêtre est plus ou moins large,

Par exemple en fonction de la vélocité.

Lorsqu'au début elle est peu fiable,

Parce qu'on n'a pas un historique très profond,

Et bien du coup cette fenêtre reste large.

Et plus ça va plus on a un historique complet,

Et plus aussi on voit que l'équipe est prédictible

-- l'historique de vélocité n'est pas en dents de scie --

Alors tous ces éléments-là peuvent être intégrés

Pour avoir une fenêtre de plus en plus serrée.

(tambours)

Un sujet où je suis souvent en désaccord,

C'est l'engagement par rapport à la vélocité.

Pour moi il n'est absolument pas question de vélocité

Quand on est en Sprint Planning etc.

Et qu'on essaie de déterminer la quantité de travail qu'on prend.

Non ! Ca nous sert à planifier,

Donc on a une prévision de ce qu'on imagine qui va sortir,

Par contre quand on arrive au moment où c'est le Sprint Planning,

Où là, très concrètement, l'équipe va décider

De la quantité de travail qu'elle prend,

Il n'est même pas question de ça !

Elle prend les stories, elle fait les tâches techniques,

Elle se projette, elle regarde le temps que ça lui prend,

Et c'est l'équipe qui s'engage !

C'est l'équipe qui doit prendre une quantité de travail

Qui est complètement réaliste -- on devrait y arriver ! --

Et juste un petit peu challenging

-- parce que le but n'est pas de se sous-charger non plus ! --

Cela veut dire qu'on n'a pas besoin de faire des calculs bizarres

"Alors voilà notre capacité habituelle,

"Mais, ah là là, aujourd'hui des gens ne sont pas là !

"Donc j'enlève tant de jours,

"Je divise de 20%, je fais des choses etc."

Oh là là : là on est en train de partir dans une planification détaillée,

À partir d'un outil qui n'est pas fait pour ça !

La vélocité c'est justement fait pour rester abstrait.

Je rappelle aussi que l'équipe Scrum est multi-disciplinaire :

On a toutes les compétences qui sont réunies

Pour aller au bout d'un projet.

Donc il ya plusieurs types de front-end,

Par exemple sur device mobile, sur le web.

On a aussi une partie back-end :

Ce ne sont pas les mêmes techno ni les mêmes manières de penser.

On a aussi tout une dimension de test, de QA,

Voire d'automatisation de test.

On a aussi une dimension de graphisme, de UI, de design,

D'expérience utilisateur.

Et toutes ces personnes-là,

On les met ensemble dans une même équipe.

En fait, les personnes ne sont pas interchangeables :

Elles peuvent éventuellement se donner des coups de main,

Parfois non, parfois un peu, parfois beaucoup,

Mais dans tous les cas

Elles ne sont pas aussi compétentes que l'expert !

Cet outil-là, la vélocité, justement elle abstrait tout ça.

Et c'est ce qu'on veut : l'Agilité c'est aussi ne pas se prendre la tête !

Alors on abstrait les choses, et on avance avec un modèle :

On apprendra des choses en cours de route.

Si on veut faire une planification détaillée,

Et normalement c'est ce qu'on a en Sprint Planning,

Cet outil-là ne peut pas servir à faire ça !

Si on veut aller dans ce détail-là : les tâches techniques !

Et là on peut lister tout ce qu'il y a à faire,

On peut vérifier, on peut peut-être se rendre compte

Que cette User Story va coincer.

Coincer pas parce qu'on n'a pas le temps dans l'absolu,

Mais parce qu'on n'a pas les bonnes compétences

À ce moment-là précisément,

Et donc il faut revoir la répartition des Stories, etc.

Product Owner : Bon bah c'est bon vous avez une vélocité de 25,

Product Owner : Il faut caser ces 20 points-là,

Product Owner : On va trouver des petits trucs en plus,

Product Owner : Mais c'est déjà bon, ça va le faire !

Dev. Back-End : Euh, non, non, je ne crois pas, là !

Dev. Back-End : Tout ce que tu as mis, quasiment,

Dev. Back-End : C'est que du back-end, de la plate-forme, etc.

Dev. Back-End : Je ne vais pas pouvoir faire seul les trois-quarts de l'itération !

Dev. Back-End : Je sais qu'on va me donner quelques coups de main,

Dev. Back-End : Mais ça va pas le faire, là !

Tech Lead : Effectivement, là il faut qu'on ait

Tech Lead : Une répartition du travail à faire qui correspond

Tech Lead : Un minimum nos compétences.

Tech Lead : Écoutez : on va faire les tâches techniques,

Tech Lead : Comme ça on verra ce qui est pertinent.

(tambours)

Un autre travers classique,

C'est de regarder pendant l'itération l'estimation

Qu'on a mis sur les tickets !

Développeur : Ah ouais !

Développeur : On a mis 3 points sur cette Story !

Développeur : Ah ouais, mais attends,

Développeur : Franchement, là, j'ai trop de taf !

Développeur : En plus je me rends compte

Développeur : Qu'il y a des trucs pourris derrière,

Développeur : Je suis en train de tout refactorer...

Développeur : Je ne sais pas comment je vais faire,

Développeur : Je pense que je ne vais pas tout faire clean...

Développeur : Parce qu'en 3 points, ça ne tiendra pas !

Quoi quoi quoi ?!? Qu'est-ce que j'entends là ?????

Attendez, déjà, 3, c'est une estimation !

Et JAMAIS on fait mal le travail !

Definition of Done ! Il faut toujours bien faire le travail !

Si c'est 3 points et qu'il ya plus de travail

Que ce qu'on a habituellement pour 3 points :

Bah c'est la vie !!!

On fait le travail très très bien, quoi qu'il arrive,

Et on ajustera, on verra le Burn Down Chart,

Et on trouvera une manière d'ajuster le plan !

Mais en tout cas, on fait le travail BIEN !

(tambours)

Mais on a aussi le travers qui est à l'opposé de ça !

Développeur : Hey ! J'ai déjà fini, c'est cool !

Développeur : Oh ? 8 points ?

Développeur : Oh bah c'est bon, je vais prendre un peu le temps,

Développeur : C'est l'occasion de faire un peu de dette,

Développeur : De chantier technique,

Développeur : Là je vais rajouter des tests dans un coin qui n'en a pas...

Développeur : C'est cool !

Moi, cette situation-là, elle me fait autant bondir que la précédente !

Ca veut dire quoi "j'ai fini en avance,"

"J'ai du temps libre, c'est cool" ?

Attend ! On n'est pas là pour fliquer les gens !

Tu as fais le travail à faire : c'est cool !

Avance ! Prends autre chose !

Il y a plein de choses super importantes !

Si c'est DONE, c'est DONE !

Pourquoi on ferait plus de choses ?

(tambours)

Et finalement moi ce que j'aime bien dire :

C'est que en tant que développeur,

Vous n'avez strictement rien à faire des points.

C'est un outil de pilotage pour le PO, ça doit être fait.

Mais pendant l'itération, vraiment, vous n'en avez rien à faire !

La planification d'itération ? Mais vous n'en avez pas besoin !

Vous faites les tâches techniques,

Vous vous engagez sur ce qui devrait passer, concrètement :

Vous faites un micro-plan.

Et puis pendant l'itération : on s'en fiche aussi !

Il se trouve que ça va plus vite que ce qu'on a prévu ?

Et bien c'est cool ! On est content et on avance.

Il se trouve que ça prend plus de temps que prévu ?

Et bien ce n'est pas grave parce que toutes façons le travail doit être bien fait.

(tambours)

Et alors : est-ce que c'est un indicateur ?

Manager : Ah pour moi l'indicateur de réussite d'un Scrum Master

Manager : C'est que la vélocité de l'équipe qu'il accompagne s'améliore.

Manager : Tout simplement !

Manager : C'est pour ça que je l'ai embauché,

Manager : C'est uniquement pour que mon équipe produise plus.

Ce n'est pas un indicateur de performance !

Les vélocité entre deux équipes ne sont absolument pas comparables,

Et même l'équipe par rapport à sa propre vélocité

Ne veut pas forcément dire grand chose pour un certain nombre de raisons.

Il y a plein de raisons pour laquelle la vélocité

Va fluctuer au cours du temps :

L'équipe grossi, l'équipe diminue,

L'équipe tourne, des personnes plus ou moins compétentes,

Ou plus ou moins junior simplement,

Des techno qui changent qu'on prend en main

Et qu'ensuite on maîtrise, et ensuite on repart à zéro,

Des User Stories de types différents,

Sur des contraintes différentes,

Des adhérences avec d'autres équipes, etc.

Plein de choses peuvent changer :

Du coup c'est assez compliqué même de l'utiliser

Pour voir que la performance d'une équipe s'améliore.

Il faut vraiment le prendre avec des pincettes quand on le regarde comme ça !

(tambours)

J'ai envie de dire : le seul indicateur qui est pertinent,

Ce n'est pas tellement est-ce que la courbe s'améliore,

C'est est-ce qu'elle est en dents de scie.

Parce que là, oui, il ya un vrai problème,

Ca par contre ça peut être mesuré : est ce que l'équipe est prédictible ?

C'est un vrai problème si la vélocité est en dents de scie,

Ca veut dire que systématiquement, une itération sur deux,

On ne finit pas les trois quarts et l'itération d'après on finit tout.

Là, il y a un vrai problème, qui peut être systémique,

Parce que finalement le DONE c'est mis en Prod

Et pour ça on se retrouve à être dépendant de tout un tas d'autres entités.

Ou ça peut être juste la manière dont l'équipe s'engage :

Systématiquement elle en prend trop,

Ou peut-être qu'elle gère mal sa recette,

Peut-être que ce n'est que le PO qui valide

-- Ca rappellera un certain Scrum Life ! --

Ca, ça peut être un indicateur très pertinent d'amélioration de l'équipe

Et notamment, en tant que Scrum Master; c'est super pertinent :

Est-ce que la vélocité de l'équipe que j'accompagne est à peu près stable ?

Ou est-ce que c'est vraiment en dents de scie ?

Ca, c'est un vrai problème !

Scrum Master : Bon j'aimerais bien qu'on parle en Rétro aujourd'hui

Scrum Master : De pourquoi on n'arrive pas à avoir une vélocité stable.

Scrum Master : Pourquoi systématiquement une itération sur deux

Scrum Master : On n'y arrive pas, en gros on rate l'itération,

Scrum Master : On livre trois machins,