Super vidéo comme toujours. Suite à mon retour d'expérience,pour l'équipe, "donner un chiffre en tant qu'estimation" est avant tout, un outil pour aligner/valider le contenu de l'US. Mais, il y en a d'autre. Si un dev dit 3 et l'autre 13, il y a forcément une incompréhension. Les Story Points devraient être complètement oublier durant le sprint en cours car effectivement, elle n'apporte que de la confusion. A ce moment, travailler en tâche technique de réalisation est le mieux. L'estimation sert à alerter le PO et à aider à aller plus loin dans le découpage métier. C'est comme ça qu'on peut aider l'équipe à disposer des US les plus petites avec la plus forte valeur métier. Le NoEstimate prend du sens dans certains cas, si l'estimation ne sert plus à aligner l'équipe sur le contenu d'une US, si l'équipe arrive à revoir des US assez fine. Cela s'obtient avec l'expérience de l'équipe. Plus on se connait, mieux on travaille ensemble, plus l'estimation est rapide voire inutile. L'estimation reste un outil pour aider l'équipe pour adresser des problématiques et ne jamais la contraindre à perdre du temps. :)
Bonne idée d'afficher quelques tweets de Vasco Duarte en début de vidéo. Et c'est bien vu aussi d'avoir souligné les effets "pervers" que peuvent amener les estimations.
@@ScrumLife Je retiens qu'il y a de bonnes raisons de ne pas s'encombrer de chiffrages comme par exemple le fait d'avoir un comportement plus agile pendant le sprint
J’ai un autre cas en tête : dans certains domaines, au sein d’entreprises d’état par exemple mais pas que, l’engagement d’un délai est une nécessité contractuelle voire légale. Penses-tu qu’on puisse fonctionner ainsi dans ce genre de cadre ? sachant que même dans un engagement aussi punitif, les observations concernant les délai et les estimations sont valables : ce ne sont que des estimations basées sur les connaissances à un temps « t » et elles rejoignent rarement la réalité.
bon courage pour expliquer ça au management ... Ca fais des mois que je me tue à le faire, j'ai montré ces vidéos, j'ai prouvé qu'estimer, à chaque coup, on se plantais, rien à faire l'argument est toujours le même "j'ai jamais vu un métier ou tu n'estimes pas, c'est la base" ... Que dire face à des gens dépassé ...
Dernière remarque qui me vient en tête et que tu as évoqué : la capacité de l’estimation à faire ressortir les choses. J’en ai parlé brièvement dans ma vidéo sur « l’interaction entre les personnes » (ua-cam.com/video/6t26lIGzXR4/v-deo.html) : il m’est arrivé de me retrouver avec des nouveaux venus dans l’équipe qui ont pu exprimer un angle d’attaque complément différent pour réaliser une US, dès leur première heure dans l’entreprise. Le poker planing leur a donné un temps et un espace sûr pour s’exprimer.
Merci Jean-Pierre. J’ajouterai un cas pratique que je vais décrire dans un prochain article c’est le cas d’une entreprise qui a besoin des estimations pour coordonner les équipes entre elles. Effectivement, ils veulent savoir quand sera prête la feature A faite par l’équipe alpha dont depends l’équipe bêta pour leur feature B. Le chef de projet aura tendance à dire que l’estimation est indispensable. De mon côté j’aurais tendance à dire que dans ce cas l’estimation cache un autre problème qui est la planification à long terme. On a besoin de l’estimation pour « garantir » une planification à long terme, ce qui révèle un mode de fonctionnement plus en projet qu’en produit non ? On peut essayer de prévoir que la feature B pourra être faite dans X sprints mais elle ne devra être planifiée que quand A sera réellement prête.
Dans le cas où on voit que des nouvelles priorités peuvent arriver pendant une itération ou que de bugs peuvent subvenir pourquoi ne pas "prévoir l imprévue" sous la forme d une user story ?
Bonjour @mokamo1798 ! C'est une excellente question, et c'est un sujet qui revient souvent ! Quand on parle de "prévoir l’imprévu", il y a différentes écoles de pensée. Certains préconisent, en effet, de laisser un peu de marge dans le sprint pour gérer les urgences et les imprévus. Par exemple, certaines équipes choisissent de ne pas remplir totalement leur capacité de sprint pour pouvoir absorber les imprévus sans compromettre les engagements pris. Par contre, formaliser cette marge sous la forme d'une user story pourrait te poser problème. Une user story, de par sa nature, doit être suffisamment claire, précise et testable. Prévoir l'incertitude sous forme de user story pourrait rendre cette dernière floue et difficile à prioriser et à mesurer. À la place, pourquoi ne pas expérimenter avec une "buffer zone" dédiée aux imprévus ? En réservant un certain pourcentage du sprint pour les bugs et les nouvelles priorités, sans les formaliser, tu gardes une certaine flexibilité. Après, tout dépend de ton équipe et de son contexte. L'important est de garder des lignes de communication ouvertes et d'ajuster les pratiques selon le retour d’expérience. Et toi, comment ton équipe gère ce genre d’imprévus actuellement ? - Robin P.S.: Si tu as d'autres questions ou souhaites partager ton expérience, n'hésite pas à le faire ici ! 😊
Mettons mon client a une liste de choses qui rapportent le plus. Seulement la 2 et la 3 ensemble rapporte plus que la 1 toute seule. N'est-il pas intéressant dans ce genre de cas d'avoir une estimation pour prioriser ?
Avec le#NoEstimates, on est en fait très proche du couple Scrum + Kanban puisque Kanban et ses métriques apportent une bonne prédictabilité sur le flux de tickets sans avoir à les estimer.
Les estimations, c'est de la mémoire musculaire : c'est souvent une mauvaise habitude. Et comme pour tout, le changement, c'est très difficile. Quand on fait du "NoEstimates", effectivement on "estime" car on essaie de savoir ce qu'on est capable de faire, mais sans mettre un temps / points / truc bizarre. Ca reste une estimation, et ça vient du "mode projet" clairement de mettre un temps ! (Donc le terme "NoEstimates" je suis pas mega fan, mais j'avoue ne pas trouver d'alternative... "NoTimeNorPoints" ? :P ) Après, j'ai pu voir que ça dépend beaucoup de la maturité d'équipe. Certaines peuvent le mettre en place (et s'ils le font gagneront du temps), d'autres non. Pour les équipes "Performantes" selon le modèle Bruce Tuckman, oui, en dessous j'ai peur que faire du NoEstimates soit une perte de valeur (car pas assez de discussion d'équipe, qui peuvent se déclencher via Poker Planning / eXtreme Quotation), mais c'est l'équipe qui décide de toute façon.
Tout à fait, ça tire beaucoup sur le flux de valeur et les "temps" de cycles basés sur le nombre d'US, je pense qu'on est en phase là-dessus ! (Je précise que je suis totalement d'accord avec le #NoEstimates, pour moi les estimations en temps / points sont un gaspillage :P ) Je voulais surtout mettre le point sur les résistances au changement, que je vois quotidiennement difficiles sur ça.
"#NoEstimates does not mean 'no estimates''" Mon interprétation du #NoEstimates : on ne supprime pas les estimations, mais on repense les éléments du backlog de façon plus atomique. Pour assurer une livraison quotidienne de valeur, même minimale. Dès le sprint #1. Même avec une équipe débutante.
Entièrement d'accord, sauf sur la dernière phrase. Une équipe débutante a beaucoup de mal à repenser les éléments de manière atomique. C'est d'ailleurs la seule vraie condition pour faire du #NoEstimates (en plus de l'environnement, mais ça...). Quand je parle de débutant, c'est "débutant en mindset", plus que débutant tout court ! Pour moi, si elle est capable de bien découper ses éléments de manière fins et uniformes, ils ne sont plus débutants.
L’estimation est faite pour le donneur d’ordre, qui par défaut est un GROS Novice ayant besoin de visibilité, mais surtout de rationaliser le montant de la facture qu’il paye. Satisfaire l’équipe où le client qui paye : il faut arbitrer, en attendant de trouver l’algorithme Quantique adapté...
Attention, si on commence à parler de budget à ne pas dépasser on n'est plus dans le même cadre que des estimations. Malgré tout le fond des discussions restent les mêmes : comment changer le contenu des discussions pour parler plutôt de valeur, comment construire la confiance, etc. À ce sujet : - #43 Comment s'engager tout en restant Agile ? ua-cam.com/video/VfCCsavI2D8/v-deo.html - #66 Quand estimation rime avec engagement ua-cam.com/video/tPndNtnOrxY/v-deo.html
Découvrez toute la communauté Scrum Life ! 👉 sl.run/5NqRaS
Super vidéo comme toujours.
Suite à mon retour d'expérience,pour l'équipe, "donner un chiffre en tant qu'estimation" est avant tout, un outil pour aligner/valider le contenu de l'US. Mais, il y en a d'autre. Si un dev dit 3 et l'autre 13, il y a forcément une incompréhension.
Les Story Points devraient être complètement oublier durant le sprint en cours car effectivement, elle n'apporte que de la confusion. A ce moment, travailler en tâche technique de réalisation est le mieux.
L'estimation sert à alerter le PO et à aider à aller plus loin dans le découpage métier. C'est comme ça qu'on peut aider l'équipe à disposer des US les plus petites avec la plus forte valeur métier.
Le NoEstimate prend du sens dans certains cas, si l'estimation ne sert plus à aligner l'équipe sur le contenu d'une US, si l'équipe arrive à revoir des US assez fine. Cela s'obtient avec l'expérience de l'équipe. Plus on se connait, mieux on travaille ensemble, plus l'estimation est rapide voire inutile.
L'estimation reste un outil pour aider l'équipe pour adresser des problématiques et ne jamais la contraindre à perdre du temps. :)
Bonne idée d'afficher quelques tweets de Vasco Duarte en début de vidéo. Et c'est bien vu aussi d'avoir souligné les effets "pervers" que peuvent amener les estimations.
Intéressant :)
Merci ! Que retiens-tu tout particulièrement de cette vidéo ?
-- JP
@@ScrumLife Je retiens qu'il y a de bonnes raisons de ne pas s'encombrer de chiffrages comme par exemple le fait d'avoir un comportement plus agile pendant le sprint
J’ai un autre cas en tête : dans certains domaines, au sein d’entreprises d’état par exemple mais pas que, l’engagement d’un délai est une nécessité contractuelle voire légale.
Penses-tu qu’on puisse fonctionner ainsi dans ce genre de cadre ? sachant que même dans un engagement aussi punitif, les observations concernant les délai et les estimations sont valables : ce ne sont que des estimations basées sur les connaissances à un temps « t » et elles rejoignent rarement la réalité.
bon courage pour expliquer ça au management ...
Ca fais des mois que je me tue à le faire, j'ai montré ces vidéos, j'ai prouvé qu'estimer, à chaque coup, on se plantais, rien à faire l'argument est toujours le même
"j'ai jamais vu un métier ou tu n'estimes pas, c'est la base" ...
Que dire face à des gens dépassé ...
Nous compatissons... As-tu vu cette vidéo plus récente qui propose des approches pour passer au NoEstimates ? ua-cam.com/video/o5tHT5aHmrA/v-deo.html
@@ScrumLife Oui, merci
Dernière remarque qui me vient en tête et que tu as évoqué : la capacité de l’estimation à faire ressortir les choses.
J’en ai parlé brièvement dans ma vidéo sur « l’interaction entre les personnes » (ua-cam.com/video/6t26lIGzXR4/v-deo.html) : il m’est arrivé de me retrouver avec des nouveaux venus dans l’équipe qui ont pu exprimer un angle d’attaque complément différent pour réaliser une US, dès leur première heure dans l’entreprise. Le poker planing leur a donné un temps et un espace sûr pour s’exprimer.
Merci Jean-Pierre. J’ajouterai un cas pratique que je vais décrire dans un prochain article c’est le cas d’une entreprise qui a besoin des estimations pour coordonner les équipes entre elles. Effectivement, ils veulent savoir quand sera prête la feature A faite par l’équipe alpha dont depends l’équipe bêta pour leur feature B.
Le chef de projet aura tendance à dire que l’estimation est indispensable. De mon côté j’aurais tendance à dire que dans ce cas l’estimation cache un autre problème qui est la planification à long terme.
On a besoin de l’estimation pour « garantir » une planification à long terme, ce qui révèle un mode de fonctionnement plus en projet qu’en produit non ?
On peut essayer de prévoir que la feature B pourra être faite dans X sprints mais elle ne devra être planifiée que quand A sera réellement prête.
Dans le cas où on voit que des nouvelles priorités peuvent arriver pendant une itération ou que de bugs peuvent subvenir pourquoi ne pas "prévoir l imprévue" sous la forme d une user story ?
Bonjour @mokamo1798 !
C'est une excellente question, et c'est un sujet qui revient souvent !
Quand on parle de "prévoir l’imprévu", il y a différentes écoles de pensée. Certains préconisent, en effet, de laisser un peu de marge dans le sprint pour gérer les urgences et les imprévus. Par exemple, certaines équipes choisissent de ne pas remplir totalement leur capacité de sprint pour pouvoir absorber les imprévus sans compromettre les engagements pris.
Par contre, formaliser cette marge sous la forme d'une user story pourrait te poser problème. Une user story, de par sa nature, doit être suffisamment claire, précise et testable. Prévoir l'incertitude sous forme de user story pourrait rendre cette dernière floue et difficile à prioriser et à mesurer.
À la place, pourquoi ne pas expérimenter avec une "buffer zone" dédiée aux imprévus ? En réservant un certain pourcentage du sprint pour les bugs et les nouvelles priorités, sans les formaliser, tu gardes une certaine flexibilité.
Après, tout dépend de ton équipe et de son contexte. L'important est de garder des lignes de communication ouvertes et d'ajuster les pratiques selon le retour d’expérience.
Et toi, comment ton équipe gère ce genre d’imprévus actuellement ?
- Robin
P.S.: Si tu as d'autres questions ou souhaites partager ton expérience, n'hésite pas à le faire ici ! 😊
@@ScrumLife Super merci beaucoup pour ces précisions ☺
Mettons mon client a une liste de choses qui rapportent le plus. Seulement la 2 et la 3 ensemble rapporte plus que la 1 toute seule. N'est-il pas intéressant dans ce genre de cas d'avoir une estimation pour prioriser ?
JP Lambert merci pour cette réponse très claire ! Effectivement tu le dis dans la vidéo, la clé c'est le découpage.
Je vais travailler là dessus 😉
Avec le#NoEstimates, on est en fait très proche du couple Scrum + Kanban puisque Kanban et ses métriques apportent une bonne prédictabilité sur le flux de tickets sans avoir à les estimer.
C'est exactement ce que je pensais
Les estimations, c'est de la mémoire musculaire : c'est souvent une mauvaise habitude.
Et comme pour tout, le changement, c'est très difficile. Quand on fait du "NoEstimates", effectivement on "estime" car on essaie de savoir ce qu'on est capable de faire, mais sans mettre un temps / points / truc bizarre. Ca reste une estimation, et ça vient du "mode projet" clairement de mettre un temps ! (Donc le terme "NoEstimates" je suis pas mega fan, mais j'avoue ne pas trouver d'alternative... "NoTimeNorPoints" ? :P )
Après, j'ai pu voir que ça dépend beaucoup de la maturité d'équipe. Certaines peuvent le mettre en place (et s'ils le font gagneront du temps), d'autres non. Pour les équipes "Performantes" selon le modèle Bruce Tuckman, oui, en dessous j'ai peur que faire du NoEstimates soit une perte de valeur (car pas assez de discussion d'équipe, qui peuvent se déclencher via Poker Planning / eXtreme Quotation), mais c'est l'équipe qui décide de toute façon.
Tout à fait, ça tire beaucoup sur le flux de valeur et les "temps" de cycles basés sur le nombre d'US, je pense qu'on est en phase là-dessus ! (Je précise que je suis totalement d'accord avec le #NoEstimates, pour moi les estimations en temps / points sont un gaspillage :P )
Je voulais surtout mettre le point sur les résistances au changement, que je vois quotidiennement difficiles sur ça.
"#NoEstimates does not mean 'no estimates''"
Mon interprétation du #NoEstimates : on ne supprime pas les estimations, mais on repense les éléments du backlog de façon plus atomique. Pour assurer une livraison quotidienne de valeur, même minimale. Dès le sprint #1. Même avec une équipe débutante.
Entièrement d'accord, sauf sur la dernière phrase. Une équipe débutante a beaucoup de mal à repenser les éléments de manière atomique. C'est d'ailleurs la seule vraie condition pour faire du #NoEstimates (en plus de l'environnement, mais ça...). Quand je parle de débutant, c'est "débutant en mindset", plus que débutant tout court !
Pour moi, si elle est capable de bien découper ses éléments de manière fins et uniformes, ils ne sont plus débutants.
L’estimation est faite pour le donneur d’ordre, qui par défaut est un GROS Novice ayant besoin de visibilité, mais surtout de rationaliser le montant de la facture qu’il paye. Satisfaire l’équipe où le client qui paye : il faut arbitrer, en attendant de trouver l’algorithme Quantique adapté...
Attention, si on commence à parler de budget à ne pas dépasser on n'est plus dans le même cadre que des estimations. Malgré tout le fond des discussions restent les mêmes : comment changer le contenu des discussions pour parler plutôt de valeur, comment construire la confiance, etc.
À ce sujet :
- #43 Comment s'engager tout en restant Agile ? ua-cam.com/video/VfCCsavI2D8/v-deo.html
- #66 Quand estimation rime avec engagement ua-cam.com/video/tPndNtnOrxY/v-deo.html