Encore un sujet très bien explicité avec beaucoup de take away à mettre en pratique ! Et franchement j'adore la petite scènette du jour... je m'y retrouve complètement !
Chapeau au SM qui garde son sang froid et expose calmement les termes du problème. Mais n'aurait-il pas du laisser l'équipe découvrir seule qu'un moyen de résoudre ce problème était de faire participer tous les membres de l'équipe aux points d'affinage ? ;o)
Argh Nicolas tu touches les limites du format ! Une scénette de 1h à faire du coaching n'aurait pas été très dynamique 😅 Clairement les acteurs ont monté de niveau ces derniers temps ! Ils sont encore meilleurs que jamais ! -- JP
Toujours aussi bon ce contenu. Merci à tous les participants qui arrivent à montrer avec dynamisme, l'intérêt de travailler mieux ensemble. Et bravo sur le format, pour lier le sujet a d'anciens contenus qu'on prend plaisir à découvrir ou redécouvrir. :)
Je crois que je vous aim.. heu que j'aime cette vidéo 🤣 super sujet, super traitement, super dynamique, bravo et merci ! Également super timing puisque je suis en train d'amener cette réflexion suite au changement de rythme de sprint, hé ben je vais coller tout le monde devant l'épisode ! 🤭🤩 Je reviens plus tard (plutôt plus tôt 😅) pour commenter le fond :)
"Réfléchissez" ! Avoir une vue d'ensemble, se poser les bonnes questions, la valeur que ça apporte, l'impact qu'on cherche à obtenir, la problématique à résoudre... tiens.. ca rappelle quelque chose 🤔🤭 (Et aussi "peut être, peut être, peut être" 😁) Ce que je vais essayer d'amener rapidement, c'est plus d'ateliers avec des parties prenantes 'process owner' qui réfléchissent aujourd'hui sans l'équipe scrum aux solutions à leur problématiques, sous le couvert organisationnel que c'est du 'process'.
Oh !!! 😲 Module 4 de la formation, pas vrai ? 😋 Bon courage Sophie ! Tu nous raconteras ce que ça donne ? -- JP
2 ปีที่แล้ว
Ma position sur le NO Estimate : solution pour retirer un outil (les estimations) utile pour l'équipe parce que détourné par ceux qui ne l'ont pas compris. Et visiblement sur le terrain la communauté a plus tendance à préférer s'en passer puisque qu'il y a moyen de faire sans.
2 ปีที่แล้ว +5
Sur le 2eme temps d'affinage, "où on creuse dans les specs", j'ai tellement vu d'équipes inclure ça dans un D.O.R. Waterfallien, que j'ai pris l'habitude de présenter la chose différemment. Dès qu'on rentre dans le comment d'une seule story, c'est qu'on est en train de prendre en charge une story qui n'est pas encore dans le backlog de sprint. Et je disais : Si on choisit de ne pas inclure cette story, ce travail est perdu, gaspillé. Arrêtons-nous là, prévoyez ce travail dans votre estimation, et on le fera pendant le sprint. "Ne pense pas à un éléphant bleu", je sais que le dev ne pourra pas empêcher de déjà y réfléchir. Mais jusqu'où vont-ils "préparer chacune de ces stories du backlog de produit qui ne seront peut-être même pas réalisées. Généralement le gaspillage est encore plus grand parce que pour éviter ce "petit gaspillage d'investigation d'une story non planifiée"... On va se forcer à la planifier, au détriment de sa pertinence pour le produit, ou de son alignement avec l'objectif de sprint. (Pas grave, ça sera pour le sprint suivant ? ... ah vous savez déjà ce que vous allez mettre dans les sprints suivants ? Mais où est la liberté de pivoter selon vos apprentissages si c'est déjà décidé, tant que vous y êtes, faites une roadmap pour les 15 -30 sprint à venir)
Très très bon épisode. De mon point de vue (et ça n'engage que moi), si on pense avoir besoin d'estimer en mode planning poker c'est qu'on ne s'est pas posé les bonnes questions à un moment donné. Ça reste des stigmates d'un besoin de contrôler quelque chose. Pareil pour le sprint planning. S'il est "torché" en 1h c'est qu'il y a quelque chose qui ne va pas ... Il y a beaucoup à échanger sur ce très bon épisode :)
@@ScrumLife Je vais expliquer mes propos (et les mesurer un peu). Souvent, on discute pour estimer et contrôler une vélocité synonyme de "responsabilité" plus que pour véritablement parler de l'item en question. Inconsciemment, on a tendance à vouloir se protéger de quelque chose. Surtout quand ces estimations et cette vélocité sont sacralisés par un burndown chart ou burnup (que je ne recommande pas non plus). Mon premier conseil :"Questionner l'équipe sur comment elle se sent dans cet exercice optionnel et pourquoi elle souhaite ou ne souhaite pas le faire (au final c'est l'équipe qui décide)". Le planning poker est à la base fait pour susciter des conversations en faisant apparaître des divergences de compréhension. L'idée est vraiment de se mettre d'accord sur ce que chacun comprend de ce qu'il y a à faire par rapport à l'item en question. Cela permet de voir s'il faut découper plus ou pas. Mon deuxième conseil serait : "Si vous voulez utiliser le planning poker ou l'extreme quotation voire les tailles de t-shirt pour clarifier votre compréhension des items les uns par rapport aux autres et partager une vision commune (pas besoin d'avoir tous les détails), soit. Mais ne conservez pas vos estimations. Jetez les avant qu'elles n'alimentent de sombres desseins". cœur Attention : Connaître sa vélocité est important pour la planification des sprints" Mon troisième conseil serait : "Mesurer votre vélocité en termes d'items livrés (je parle bien d'items et pas d'US)" Et mon quatrième: "Utiliser cette vélocité pour ajuster votre plan de livraison par rapport à ce qui était envisagé dans la roadmap et générer des conversations sur ce qui est prioritaire" Affiner est donc capital pour maintenir le rythme mais attention, comme le dit Claude Aubry : "c'est un équilibre subtil entre tout définir et ne rien faire avant le sprint" Et estimer est un moyen.
Petite nuance supplémentaire : un outil est très rarement voire jamais "mauvais". Ce qu'il faut questionner c'est le pour quoi et le comment on l'utilise.
Merci beaucoup pour tous ces partages, Eirian ! Très pertinents 🤩 Est-ce que globalement dans tes équipes tu arrives à atteindre cet équilibre subtil entre tout définir et ne rien faire avant le sprint ? -- JP
@@ScrumLife Avec plaisir. On est passé par toutes les expériences possibles. On a trop affiné, puis pas assez, avec estimations, sans estimations, en petit comité, avec toute l'équipe etc ... pour finir par trouver l'équilibre qui nous allait bien. C'est à dire plus d'estimation, des sprints d'une semaine et 1h d'affinage max par sprint. Bientôt un nouveau challenge avec une nouvelle équipe pour moi (courant février). Ce sera l'occasion de partager une nouvelle expérience en partant de zéro (et je vous dois un feedback neatro quand l'heure de la rétro aura sonné)
Super vidéo, petit retour sur la vidéo, ça aurais était cool un petit rappel de la définition de Refinement même si par le contexte on arrive à comprendre.
Ah mais ouiiiiiii ! ! ! Après c'est vrai que c'est une vidéo "conseils" on présentera tout ça plus dans le détail dans la prochaine vidéo plus "didactique". -- JP
@@ScrumLife Salut Constantin, ça se fait ça en plusieurs ateliers de découpage et validations entre PO, devs et moi pour accompagner. D'abord la PO présente aux équipes concernées le sujet à sortir (généralement sous forme d'epic chez nous), nous indique les grandes priorités, ce qui peut être négociable, etc. Ensuite les devs se réunissent pour décomposer le travail en Features et Stories comme ils l'ont compris. Ils échangent autant que nécessaire avec la PO de manière ponctuelle. Dès qu'ils ont fini leur découpage, on se revoit pour qu'ils nous présentent ça, on ajuste si besoin et si c'est ok, ils commencent à estimer les stories pour qu'on puisse préparer la session de planning.
Merci pour la prise de recul que vous proposez sur le 'Backlog Refinement', en 4 thèmes. Cette mise en perspective des buts recherchés selon les thèmes et leur relocalisation dans le Sprint Planning est un bon rappel, pour éviter un Cycle en V qui ne dit pas son nom. Pour le "No Estimate", je reste perplexe quant à la forme proposée. '1' pour exprimer que 'quelque chose' rentre dans le Sprint, '>1' sinon. Si 'quelque chose' est un "Goal de Sprint atteignable", OK, c'est une sorte de vote de confiance. Mais si on parle d'un besoin exprimé sous forme de User Story ... Je séche. Est-ce à dire 'Avec les informations dont nous disposons actuellement, même si nous décidons de créer un incrément de Produit uniquement pour cette US, il nous faudrait plus d'un Sprint" ? Ainsi, on ne s'interdit pas en Sprint Planning de répondre à plusieurs US qui permettent d'atteindre le Goal de Sprint, mais on sait à minima qu'aucune des US seule n'est irréalisable en un seul Sprint ? Merci pour votre aide :o)
@@ScrumLife Bonjour. Oui, c est plus clair. Constantin a par exemple précisé qu'il demandait a ce que le decoupage des US permette de raisonnablement supposer qu'elles sont réalisables en 1 à 2 jours max. Donc dans ce cas effectuer du "No Estimate" avec seulement 2 cartes à du sens. Merci pour vos éclaircissements !
2 ปีที่แล้ว +1
Exactement les questions que nous nous sommes posé à notre dernière rétro. Le "problème" des ateliers c'est que souvent ils doivent être fait en présentiel quand notre PBR est en remote. Si vous avez des exemples d'ateliers pour la PBR (ou démarrage) en remote, je suis preneur. Je vais aller jeter un coup d’œil à ceux que vous avez donné. Merci !
Salut Frédéric ! Forcément à distance c'est moins fluide, mais globalement on y arrive ! À vrai dire on pourrait faire des vidéos spécifiquement sur le travail à distance car on peut essayer de tirer parti de certains changements de dynamique plutôt que de les vivre comme des contraintes. Et sinon, alors, qu'est-ce que vous vous êtes dit durant votre rétro ? Quelles actions avez-vous pris ? Raconte-nous ! -- JP
2 ปีที่แล้ว
@@ScrumLife Oui je trouve que les réunions à distance ont certains avantages (et des inconvénients). On va peut-être essayer de faire un exemple mapping avec un tableau partagé (comme pour nos rétros). Justement à la dernière rétro j'ai demandé à l'équipe de décrire le pire sprint qu'il pourrait arriver. Ça a beaucoup tourné autour du découpage, de l’incompréhension des US, de critères découverts à la fin, etc. On a donc exploré des axes d'améliorations de nos PBR et sprint planning. Votre vidéo est tombé à point nommé ^^ La crainte aussi est que ces réunions s'éternisent. Une solution est de changer le format (qui est effectivement comme vous le décrivez dans la vidéo donc pas très engageant) pour quelque chose de plus dynamique, productif et engageant.
le "No Estimate" va faire trembler dans les chaumières. Nous avons décidé en équipe de ne prendre les chiffres de 1 à 8 sur la suite de Fibonacci et cela a déjà fait énormément gagner du temps sur les estimations. On va essayé le No Estimate, on verra bien. Au pire on débriefera durant la rétrospective
J’espère que tu nous tiendra au courant de ce que donne cet essai. Aujourd’hui les estimations que vous faite servent à quoi concrètement ? - Constantin
@@ScrumLife on utilise le poker planning pour estimer les US durant le sprint planning et calculer l'effort et la vélocité. On s'en sert aussi pour faire du pair programming quand 2 estimation differe trop. Ça permet de partager les connaissances entre développer
J'ai rencontré plusieurs problèmes en demandant "à quoi servent les estimations": 1) Les équipes ne conçoivent pas de ne pas faire d'estimation 2) C'est le process. On ne sais pas pourquoi ni pour qui mais c'est obligatoire. 2bis) On sait pour qui mais il n'y a pas de transparence, donc pour autant qu'on en sache, on ne sais pas si et comment elle sont utilisées. Personnellement je n'aime pas les estimations dans un but prédictif mais j'aime bien de manière rétrospective. Si on estimait X mais au final c'est >X, on peut se poser la question de pourquoi? Et si les "erreurs" d'estimation sont fréquentes, est-ce que l'équipe doit revoir certain points de ses méthodes de travail (ou peut-être que les estimations sont par nature fausses ou indignes de confiance)
Faut il le faire à des moments précis ? Combien de US doit on affiner avant le prochain sprint planning ? Faut il les estimer la ou en sprint planning ?
- Ca dépend vraiment de la dynamique de l'équipe. A certaines périodes il faudra peut-être que ce soit un moment précis, à d'autres, plus à la demande ? - Je ne parlerais pas d'US mais d'objectif : a-t-on assez d'info pour avoir une bonne vision de ce qu'on doit accomplir ? - En planning, l'estimation étant : est-ce qu'on estime pouvoir le faire dans ce sprint ? Qu'en dis-tu ? -- Constantin
Merci Nicolas ! Voici une playlist de quelques vidéos : th-cam.com/play/PLxTb_ZC4kmrT4eXyWbUZkTpqMua1RZ2bW.html Si tu veux en savoir plus n'hésite pas à poser une question :) -- Constantin
C'est à mon sens un travail d'équipe, mais il peut y avoir plusieurs affinage peut-être : 1/ Affiner les info, donc le/la PO va observer les utilisateurs, leur poser des questions, regarder les analytics, etc. 2/ Affiner le fait d'avoir les bonnes info en en parlant aux dev qui vont peut-être soulever des interrogations ? T'en dis quoi ? -- Constantin
![เป็นไปได้ไหม - WanMai [Performance Video]](http://i.ytimg.com/vi/Eh5hItD4Mr0/mqdefault.jpg)
Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇
Nous en échangerons lors du 🔴Live jeudi : sl.run/BVjT78
Encore un sujet très bien explicité avec beaucoup de take away à mettre en pratique ! Et franchement j'adore la petite scènette du jour... je m'y retrouve complètement !
Chapeau au SM qui garde son sang froid et expose calmement les termes du problème.
Mais n'aurait-il pas du laisser l'équipe découvrir seule qu'un moyen de résoudre ce problème était de faire participer tous les membres de l'équipe aux points d'affinage ? ;o)
Argh Nicolas tu touches les limites du format ! Une scénette de 1h à faire du coaching n'aurait pas été très dynamique 😅
Clairement les acteurs ont monté de niveau ces derniers temps ! Ils sont encore meilleurs que jamais !
-- JP
Toujours aussi bon ce contenu. Merci à tous les participants qui arrivent à montrer avec dynamisme, l'intérêt de travailler mieux ensemble. Et bravo sur le format, pour lier le sujet a d'anciens contenus qu'on prend plaisir à découvrir ou redécouvrir. :)
Oui, ils se sont donnés à fond les acteurs ! 😁
Pourrais-tu nous dire quels sont ces anciens contenus que tu apprécies de redécouvrir ?
-- JP
Je crois que je vous aim.. heu que j'aime cette vidéo 🤣 super sujet, super traitement, super dynamique, bravo et merci !
Également super timing puisque je suis en train d'amener cette réflexion suite au changement de rythme de sprint, hé ben je vais coller tout le monde devant l'épisode ! 🤭🤩
Je reviens plus tard (plutôt plus tôt 😅) pour commenter le fond :)
Merciiiiiiiiiii 🤗
C'est quoi le conseil qui ressort le plus pour toi dans cet épisode ?
-- JP
"Réfléchissez" !
Avoir une vue d'ensemble, se poser les bonnes questions, la valeur que ça apporte, l'impact qu'on cherche à obtenir, la problématique à résoudre... tiens.. ca rappelle quelque chose 🤔🤭
(Et aussi "peut être, peut être, peut être" 😁)
Ce que je vais essayer d'amener rapidement, c'est plus d'ateliers avec des parties prenantes 'process owner' qui réfléchissent aujourd'hui sans l'équipe scrum aux solutions à leur problématiques, sous le couvert organisationnel que c'est du 'process'.
Oh !!! 😲
Module 4 de la formation, pas vrai ? 😋
Bon courage Sophie ! Tu nous raconteras ce que ça donne ?
-- JP
Ma position sur le NO Estimate : solution pour retirer un outil (les estimations) utile pour l'équipe parce que détourné par ceux qui ne l'ont pas compris.
Et visiblement sur le terrain la communauté a plus tendance à préférer s'en passer puisque qu'il y a moyen de faire sans.
Sur le 2eme temps d'affinage, "où on creuse dans les specs", j'ai tellement vu d'équipes inclure ça dans un D.O.R. Waterfallien, que j'ai pris l'habitude de présenter la chose différemment.
Dès qu'on rentre dans le comment d'une seule story, c'est qu'on est en train de prendre en charge une story qui n'est pas encore dans le backlog de sprint.
Et je disais : Si on choisit de ne pas inclure cette story, ce travail est perdu, gaspillé. Arrêtons-nous là, prévoyez ce travail dans votre estimation, et on le fera pendant le sprint.
"Ne pense pas à un éléphant bleu", je sais que le dev ne pourra pas empêcher de déjà y réfléchir. Mais jusqu'où vont-ils "préparer chacune de ces stories du backlog de produit qui ne seront peut-être même pas réalisées.
Généralement le gaspillage est encore plus grand parce que pour éviter ce "petit gaspillage d'investigation d'une story non planifiée"... On va se forcer à la planifier, au détriment de sa pertinence pour le produit, ou de son alignement avec l'objectif de sprint. (Pas grave, ça sera pour le sprint suivant ? ... ah vous savez déjà ce que vous allez mettre dans les sprints suivants ? Mais où est la liberté de pivoter selon vos apprentissages si c'est déjà décidé, tant que vous y êtes, faites une roadmap pour les 15 -30 sprint à venir)
Très très bon épisode.
De mon point de vue (et ça n'engage que moi), si on pense avoir besoin d'estimer en mode planning poker c'est qu'on ne s'est pas posé les bonnes questions à un moment donné. Ça reste des stigmates d'un besoin de contrôler quelque chose.
Pareil pour le sprint planning. S'il est "torché" en 1h c'est qu'il y a quelque chose qui ne va pas ...
Il y a beaucoup à échanger sur ce très bon épisode :)
Merci Eirian ! As-tu un conseil à partager ? On en parlerait jeudi !
-- JP
@@ScrumLife
Je vais expliquer mes propos (et les mesurer un peu).
Souvent, on discute pour estimer et contrôler une vélocité synonyme de "responsabilité" plus que pour véritablement parler de l'item en question.
Inconsciemment, on a tendance à vouloir se protéger de quelque chose.
Surtout quand ces estimations et cette vélocité sont sacralisés par un burndown chart ou burnup (que je ne recommande pas non plus).
Mon premier conseil :"Questionner l'équipe sur comment elle se sent dans cet exercice optionnel et pourquoi elle souhaite ou ne souhaite pas le faire (au final c'est l'équipe qui décide)".
Le planning poker est à la base fait pour susciter des conversations en faisant apparaître des divergences de compréhension.
L'idée est vraiment de se mettre d'accord sur ce que chacun comprend de ce qu'il y a à faire par rapport à l'item en question.
Cela permet de voir s'il faut découper plus ou pas.
Mon deuxième conseil serait : "Si vous voulez utiliser le planning poker ou l'extreme quotation voire les tailles de t-shirt pour clarifier votre compréhension des items les uns par rapport aux autres et partager une vision commune (pas besoin d'avoir tous les détails), soit. Mais ne conservez pas vos estimations. Jetez les avant qu'elles n'alimentent de sombres desseins".
cœur
Attention : Connaître sa vélocité est important pour la planification des sprints"
Mon troisième conseil serait : "Mesurer votre vélocité en termes d'items livrés (je parle bien d'items et pas d'US)"
Et mon quatrième: "Utiliser cette vélocité pour ajuster votre plan de livraison par rapport à ce qui était envisagé dans la roadmap et générer des conversations sur ce qui est prioritaire"
Affiner est donc capital pour maintenir le rythme mais attention, comme le dit Claude Aubry : "c'est un équilibre subtil entre tout définir et ne rien faire avant le sprint"
Et estimer est un moyen.
Petite nuance supplémentaire : un outil est très rarement voire jamais "mauvais". Ce qu'il faut questionner c'est le pour quoi et le comment on l'utilise.
Merci beaucoup pour tous ces partages, Eirian ! Très pertinents 🤩
Est-ce que globalement dans tes équipes tu arrives à atteindre cet équilibre subtil entre tout définir et ne rien faire avant le sprint ?
-- JP
@@ScrumLife Avec plaisir. On est passé par toutes les expériences possibles. On a trop affiné, puis pas assez, avec estimations, sans estimations, en petit comité, avec toute l'équipe etc ... pour finir par trouver l'équilibre qui nous allait bien. C'est à dire plus d'estimation, des sprints d'une semaine et 1h d'affinage max par sprint.
Bientôt un nouveau challenge avec une nouvelle équipe pour moi (courant février). Ce sera l'occasion de partager une nouvelle expérience en partant de zéro (et je vous dois un feedback neatro quand l'heure de la rétro aura sonné)
Super vidéo,
petit retour sur la vidéo, ça aurais était cool un petit rappel de la définition de Refinement même si par le contexte on arrive à comprendre.
Ah mais ouiiiiiii ! ! !
Après c'est vrai que c'est une vidéo "conseils" on présentera tout ça plus dans le détail dans la prochaine vidéo plus "didactique".
-- JP
Excellent le Poker planning No estimate 😍
Oui ! Ca aide pas mal à faire le pont entre les anciennes et nouvelles habitudes.
Tu comptes essayer ?
-- JP
Vraiment top cette vidéo, très pertinente et très claire comme les précédentes 👍
Merci Stéphane ! Comment se passe les affinages chez toi ?
-- Constantin
@@ScrumLife Salut Constantin, ça se fait ça en plusieurs ateliers de découpage et validations entre PO, devs et moi pour accompagner.
D'abord la PO présente aux équipes concernées le sujet à sortir (généralement sous forme d'epic chez nous), nous indique les grandes priorités, ce qui peut être négociable, etc.
Ensuite les devs se réunissent pour décomposer le travail en Features et Stories comme ils l'ont compris. Ils échangent autant que nécessaire avec la PO de manière ponctuelle.
Dès qu'ils ont fini leur découpage, on se revoit pour qu'ils nous présentent ça, on ajuste si besoin et si c'est ok, ils commencent à estimer les stories pour qu'on puisse préparer la session de planning.
Merci pour la prise de recul que vous proposez sur le 'Backlog Refinement', en 4 thèmes.
Cette mise en perspective des buts recherchés selon les thèmes et leur relocalisation dans le Sprint Planning est un bon rappel, pour éviter un Cycle en V qui ne dit pas son nom.
Pour le "No Estimate", je reste perplexe quant à la forme proposée. '1' pour exprimer que 'quelque chose' rentre dans le Sprint, '>1' sinon.
Si 'quelque chose' est un "Goal de Sprint atteignable", OK, c'est une sorte de vote de confiance.
Mais si on parle d'un besoin exprimé sous forme de User Story ... Je séche.
Est-ce à dire 'Avec les informations dont nous disposons actuellement, même si nous décidons de créer un incrément de Produit uniquement pour cette US, il nous faudrait plus d'un Sprint" ?
Ainsi, on ne s'interdit pas en Sprint Planning de répondre à plusieurs US qui permettent d'atteindre le Goal de Sprint, mais on sait à minima qu'aucune des US seule n'est irréalisable en un seul Sprint ?
Merci pour votre aide :o)
Salut Nicolas, on en parlé pendant le Live, est-ce que cela t'a apporté des éléments de réponse ?
👉 th-cam.com/video/3vU4TSXWMSo/w-d-xo.html
-- JP
@@ScrumLife Bonjour. Oui, c est plus clair. Constantin a par exemple précisé qu'il demandait a ce que le decoupage des US permette de raisonnablement supposer qu'elles sont réalisables en 1 à 2 jours max. Donc dans ce cas effectuer du "No Estimate" avec seulement 2 cartes à du sens. Merci pour vos éclaircissements !
Exactement les questions que nous nous sommes posé à notre dernière rétro. Le "problème" des ateliers c'est que souvent ils doivent être fait en présentiel quand notre PBR est en remote. Si vous avez des exemples d'ateliers pour la PBR (ou démarrage) en remote, je suis preneur. Je vais aller jeter un coup d’œil à ceux que vous avez donné. Merci !
Salut Frédéric ! Forcément à distance c'est moins fluide, mais globalement on y arrive !
À vrai dire on pourrait faire des vidéos spécifiquement sur le travail à distance car on peut essayer de tirer parti de certains changements de dynamique plutôt que de les vivre comme des contraintes.
Et sinon, alors, qu'est-ce que vous vous êtes dit durant votre rétro ? Quelles actions avez-vous pris ? Raconte-nous !
-- JP
@@ScrumLife Oui je trouve que les réunions à distance ont certains avantages (et des inconvénients). On va peut-être essayer de faire un exemple mapping avec un tableau partagé (comme pour nos rétros). Justement à la dernière rétro j'ai demandé à l'équipe de décrire le pire sprint qu'il pourrait arriver. Ça a beaucoup tourné autour du découpage, de l’incompréhension des US, de critères découverts à la fin, etc. On a donc exploré des axes d'améliorations de nos PBR et sprint planning. Votre vidéo est tombé à point nommé ^^
La crainte aussi est que ces réunions s'éternisent. Une solution est de changer le format (qui est effectivement comme vous le décrivez dans la vidéo donc pas très engageant) pour quelque chose de plus dynamique, productif et engageant.
Top Frédéric ! Merci pour ton partage 💪
-- JP
Bonjour, Très intéressant! Est-ce qu'il y a d'autres façons de faire du NoEstimate?
le "No Estimate" va faire trembler dans les chaumières. Nous avons décidé en équipe de ne prendre les chiffres de 1 à 8 sur la suite de Fibonacci et cela a déjà fait énormément gagner du temps sur les estimations. On va essayé le No Estimate, on verra bien. Au pire on débriefera durant la rétrospective
J’espère que tu nous tiendra au courant de ce que donne cet essai.
Aujourd’hui les estimations que vous faite servent à quoi concrètement ?
- Constantin
@@ScrumLife on utilise le poker planning pour estimer les US durant le sprint planning et calculer l'effort et la vélocité. On s'en sert aussi pour faire du pair programming quand 2 estimation differe trop. Ça permet de partager les connaissances entre développer
J'ai rencontré plusieurs problèmes en demandant "à quoi servent les estimations":
1) Les équipes ne conçoivent pas de ne pas faire d'estimation
2) C'est le process. On ne sais pas pourquoi ni pour qui mais c'est obligatoire.
2bis) On sait pour qui mais il n'y a pas de transparence, donc pour autant qu'on en sache, on ne sais pas si et comment elle sont utilisées.
Personnellement je n'aime pas les estimations dans un but prédictif mais j'aime bien de manière rétrospective. Si on estimait X mais au final c'est >X, on peut se poser la question de pourquoi? Et si les "erreurs" d'estimation sont fréquentes, est-ce que l'équipe doit revoir certain points de ses méthodes de travail (ou peut-être que les estimations sont par nature fausses ou indignes de confiance)
Faut il le faire à des moments précis ? Combien de US doit on affiner avant le prochain sprint planning ? Faut il les estimer la ou en sprint planning ?
- Ca dépend vraiment de la dynamique de l'équipe. A certaines périodes il faudra peut-être que ce soit un moment précis, à d'autres, plus à la demande ?
- Je ne parlerais pas d'US mais d'objectif : a-t-on assez d'info pour avoir une bonne vision de ce qu'on doit accomplir ?
- En planning, l'estimation étant : est-ce qu'on estime pouvoir le faire dans ce sprint ?
Qu'en dis-tu ?
-- Constantin
Mais finalement quel est le but premier de l’affinage ? 🧐
Salut Céline ! C'est une bonne question.
D'avoir assez d'information pour savoir ce qu'il ne faut pas faire ?
-- Constantin
Bravo une fois de plus pour cette vidéo. Question concernant les estimations : où puis-je trouver un ensemble de pratiques autres ?
Merci Nicolas !
Voici une playlist de quelques vidéos : th-cam.com/play/PLxTb_ZC4kmrT4eXyWbUZkTpqMua1RZ2bW.html
Si tu veux en savoir plus n'hésite pas à poser une question :)
-- Constantin
Pour ma part le refinement ça a toujours été un peu flou… et je vois que c’est voulu 😏.
En effet, ça peut vouloir dire des choses totalement différente suivant les équipes.
-- Constantin
Le PO peut / doit il affiner seul ou avec toute l’équipe …. Cette activité est en effet peu encadrée dans le Scrum Guide.
C'est à mon sens un travail d'équipe, mais il peut y avoir plusieurs affinage peut-être :
1/ Affiner les info, donc le/la PO va observer les utilisateurs, leur poser des questions, regarder les analytics, etc.
2/ Affiner le fait d'avoir les bonnes info en en parlant aux dev qui vont peut-être soulever des interrogations ?
T'en dis quoi ?
-- Constantin