Le Planning Poker et les ESTIMATIONS Agile - Scrum Life 24
Вставка
- Опубліковано 14 жов 2024
- 🎁 Le guide du Scrum Master compétent 👉 sl.run/LbI4e9
Ca se passe comment les estimations en Agile ? Et c'est quoi ce "Planning Poker" ? #UserStoryPoints #EstimationCollective #Scrum
💜️ La communauté Scrum Life 👉 sl.run/r0DrHm
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
Ce que représentent les "points" : CURSE bit.ly/story-po...
Scrum Life 19 - Application de la vélocité aux points : • Comment bien utiliser ...
Scrum Life 21 - Utilisation des points pour faire un suivi projet avec le Burn-Up : • Pilotage Agile avec le...
Découvrez toute la communauté Scrum Life ! 👉 sl.run/djx5pg
Merci ! Vous gérez JP et la team. Bonne continuation.
merci Jean Pierre. Très clair! J'aime bien "c'est celui qui fait qui sait" (très lean, canal historique!). Je l'ai utilisé récemment dans une sensibilisation à l'estimation ;-)
Le lien pour l’article sur l’estimation des user stories avec CURSE, mais il apparaît dans la vidéo et j’ai pu le récupérer. Merci pour cette chaîne elle est géniale !!
Merci pour la vidéo. Dans mon ancienne équipe les développeurs faisait l'estimation en heure et avec les points
Le planning poker est organisé dans la phase d'incubation sous cette forme: 1/3 environ des stories du backlog sont estimées à la grosse louche. Puis la moyenne des story points est assignées aux autres stories non-estimées. Les points seront revus durant le sprint planning. En général, on vise plutôt juste. Seules les cartes allant de 0.5 à 13 restent.
Ensuite, de manière sporadique, le PO organise un planning poker pour des stories qui tombent du ciel et acceptées dans la release.
Une chose à améliorer: essayer de cesser de parler technique :-)
Et une fois de plus, bravo pour la vidéo :-) Un vrai régal !
"Long peut-être mais bon sûrement" (voire Excellent !)
Ohhhhh ... il y a même un début de bêtisier :)
Merci Jean-Pierre
Personnellement, cela ne ma pas du tout gêné :)
11 min pour apprendre, réviser et/ou approfondir les basiques, ce n'est pas grand chose !
J'attends le ScrumLife dédié à l'eXtreme quotation :) car mon "soucis" est toujours de répondre, en début de projet, à la question : "Combien de temps ça va prendre ?" (sous entendu : ça va me coûter combien ?).
Bref : comment faire une estimation de la durée du projet sans y passer trop de temps.
Gantt et la planif détaillée, c'est comme le chocolat : C'est bon ... mais trop, c'est la crise de foie (ou foi si tu ne crois plus au planning que tu es en train de créer :) ).
@+
Bravo, ta chaine est vraiment parfaite ! Wow j’adore
Merci ! ! ! Dans quel domaine travailles-tu ?
-- JP
Cette chaîne est top !
Merci beaucoup !!! Qu'est-ce que tu préfères dans la chaîne ? Quel est ton épisode préféré ?
En fait, j’aime beaucoup les illustrations et les petites scènettes qui mettent bien en situation. Ça peut vraiment apporter quelque chose pour ceux qui veulent parfaire leurs connaissances sur Scrum :-)
Merci pour cette vidéo et ces conseils !!
Deux questions me viennent en tête vis à vis de cette méthode
- Si on doit faire estimer qu’aux développeurs, qu’en est-il de tout le travail de design en amont ? Sur une vision produit, une estimation de charge n’est pas uniquement technique.
- On estime la difficulté mais pas du tout l’impact la dedans. C’est pas parce qu’une user story est difficile qu’elle sera plus impactante, comment intégrer cette vision en plus ?
Salut, pour le premier point c'est une imprécision de la vidéo : par "développeur" il faut le comprendre au sens de Scrum, c'est à dire un des membres de la Scrum Team qui contribue à la construction du produit. Dans le domaine du logiciel, cela inclut donc aussi tout le travail de conception, de validation, de test, de déploiement... Nous sommes donc d'accord et la faute est la mienne, d'avoir été imprécis dans cette vidéo !
Quant à la notion d'impact, elle est essentielle aux éléments du backlog en général et aux User Stories en particulier. La logique d'estimation sert notamment à faire des calculs de type ROI visé, mettant en relation l'impact visé avec l'effort estimé. Ce n'est effectivement pas du tout évoqué dans cette vidéo.
Voici quelques Scrum Life en lien avec ce sujet :
- L'impact du produit - ua-cam.com/video/wD5WeJ7xde8/v-deo.html
- Backlog Produit - Evaluez-vous la Business Value ? ua-cam.com/video/WInTWb94WUg/v-deo.html
- N'avoir qu'une seule priorité grâce au coût du délai - ua-cam.com/video/Z3Hh5tDNXE4/v-deo.html
Est-ce que mes réponses t'éclairent ?
-- JP
merci!
à quel moment du sprint planning doit se passer le poker planning?
Dans la vidéo sur le sprint planning, on a vu qu'on devait définir des tâches techniques pour estimer si l'on doit prendre ou pas une US dans le sprint.
J'en déduis qu'il faut estimer les US, plutôt en refinement, parce que sinon, en sprint planning, ça obligerait à choisir les US en définissant les tâches techniques, puis à les estimer ensuite avec la contrainte de ne pas parler technique, ça se contredit un peu.
Oui, tout à fait ! L'estimation -- si vous faites des estimations, ce n'est pas obligatoire -- se ferait plutôt en refinement.
Les estimations agiles servent à planifier au-delà du prochain sprint. Pour planifier le sprint courant, les tâches techniques suffisent et sont plus adaptées.
Dans ton équipe, faites-vous des refinements ? En quoi consistent-ils ?
-- JP
Vous êtes parfait ! Merci
Merci ! Utilisais-tu déjà le Planning Poker avant ?
-- JP
@@ScrumLife oui, souvent ça aide à mieux s'organiser ... ( surtout à ne pas être exploiter par certains boîte)
+1 pour l’intro de California Love ❤️ - 2Pac
Ah ah ! J'espère que tu as retenu autre chose de la vidéo 😋
-- JP
vidéo très intéressante :)
Merci beaucoup merci infiniment pour cette chaine :) :) :)
Super vidéo ! 👍
Merci !!! 🤗
Qu'est-ce que tu retiens plus particulièrement de cette vidéo ?
-- JP
@jplambert As-tu un avis sur le pointage des bugs, des spikes, des déploiements... J’aimerais entendre ton avis là-dessus. Devons-nous leur donner des points ou non :)
plusieurs fois quand je vois le titre le la vidéo je me dis "oh celle là elle va être chiante et je vais rien apprendre" et à chaque fois je me plante :-) félicitation !
j'ai tout de même une question:
Comment faire quand l'équipe ne peut pas estimer tant qu'elle est pas rentrer dans la technique, tant qu'on a pas découper en taches techniques (ou alors il le font dans le tête).
Çà ne peux pas arriver que l'équipe dise clairement "on a compris le besoin, on a plus de question, mais il faut qu'on discute du comment parce là on voit pas comment le faire ?"
Si bien sûr, auquel cas la sagesse voudrait qu'on arrête d'en discuter pour faire une investigation technique.
Il y a plusieurs manières de s'y prendre mais en gros ça pourrait être quelque chose comme cela :
- Ca prend 5 minutes à parler techniques, parlons-en en séance (par contre il faut vraiment que ça ne prenne que quelques minutes, on peut timeboxer éventuellement)
- Ca prend 1 ou 2 heures, l'équipe le fait de manière informelle dans une autre réunion, lors d'un moment de partage entre développeurs, ou simplement un des dev en solo avant de recroiser avec ses collègues
- Ca prend 1/2 journée ou plus, on rentre l'investigation technique dans le backlog par exemple avec un spike, tel qu'expliqué dans le Scrum Life #64 : ua-cam.com/video/admFBOy8kAg/v-deo.html
Evidemment, tout cela est à ajuster à votre contexte. Par exemple dans cette équipe nous prenions une journée dédiée par itération pour mélanger tout cela de manère fluide : jp-lambert.me/l%C3%A9quipe-ne-trouve-pas-le-temps-de-pr%C3%A9parer-les-sujets-%C3%A0-venir-1e31614863eb
@@ScrumLife top le forum hors guidon !! merci pour ces idées
Merci :)
Zut! Le dev avec le bouclier c'est moi!
Ah bah non en fait, je suis pas testeur. (Mais j'ai quand même toujours tendance à vouloir mettre plus que les autres)
Bien expliqué ! rien à dire
bonjour bonjour! je ne vois pas le lien pour l'article?
Bonjour, de quel article parles-tu ?
😁✌️
Merci ! Qu'est-ce que tu retiens tout particulièrement de cette vidéo ?
-- JP
une question au niveau de l' architecte, je comprends pas bien pkoi son estimation n' est pas prise, le testeur ne fait pas la feature en tant que tel comparé au developeur mais fait partie integrante de l' equipe au meme titre que l' architecte et pourtant le testeur estime et non l' architecte?
Justement dans l'exemple l'architecte ne fait pas partie de l'équipe, contrairement au testeur. Désolé de n'avoir pas rendu cela plus explicite.
Enfin si bien sûr que le testeur va faire la feature en tant que tel : le test fait partie intégrante des activités de développement. C'est un sacré problème si on n'intègre pas l'effort de test dans les estimations.
@@ScrumLife ok cool alors
Bonjour à tous
La page CURSE nous a inspiré cet outil qui a bien plu à notre équipe : astenor.free.fr/CURSE/ . Enjoy !
Wow, intéressant ! Merci du partage. Vous l'utilisez de manière routinière ? Comment ça fonctionne ? L'introduction d'un outil pouvant casser la dynamique d'une réunion. À quoi ça ressemble en pratique ?
Quelqu'un a une idée sur l'estimation Walla planing? Merci
ouch x^2 et et e^x ?
Est-ce que tu peux préciser Luc ? :)
Pourquoi parler ce jargon alors que la traduction ne prend pas beaucoup plus de temps ?
Par habitude personnelle et professionnelle. Je ne dis pas que c'est bien ! Désolé 😅
Ce n'était pas un reproche mais plus je me renseigne sur le scrum et plus je m'aperçois que c'est une manière de fonctionner plutôt naturelle que j'ai eu tendance à mettre en place moi même. A l'inverse, tous ces termes ça me décourage, on dirait un jeu vidéo ou plutôt une surcouche logicielle alors que le scrum est plutôt intuitif je trouve...
Cc