Les digressions techniques en Backlog Refinement/Grooming - Scrum Life 22

🎁 Le guide du Scrum Master compétent 👉 sl.run/WkJii5
Est-ce que ça vous parle les digressions techniques pendant les sessions de Backlog Refinement ou Backlog Grooming ? Ca vous arrive souvent ? Quand ça arrive, cela dure quelques minutes ou bien cela accapare tout le reste de la réunion ?
Personnellement, je ne l'ai que trop souvent vu ! Aussi dans ce Scrum Life je vous donne quelques pistes pour réussir à recadrer la réunion lorsque cela arrive 😁
💜️ La communauté Scrum Life 👉 sl.run/emolnw
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
- Scrum Life 12 à propos du découpage de User Story : • "Impossible de découpe...
- Réflexion sur l'impact d'avoir un profil technique ou non pour un Scrum Master : jp-lambert.me/...

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/eVLaCb

[@naveedmirza1261]

Hello Christophe Merci pour tout ces tops super utiles

[@YBCause]

R.O.T.I : Return On Time Invested Aaaaaaah je sais enfin à quoi correspond cet acronyme gourmet !

[@biancheriolivier5668]

Merci pour la video sur le Burn Up... Très enrichissante

[@jarod51]

Très bon le ROTI ! :)

[@sanaar1150]

Tout ça me parle énormement ! Merci pour cette vidéo ^^

[@YBCause]

En daily scrum ça arrive aussi parfois, mais c'est plus évident à ce moment-là de dire "hop hop hop vous parlerez de ça après entre vous !"

[@CoinCoin86]

Ca me parle aussi. Parfois j'ai même l'inverse, des devs qui ne s'intéressent pas trop au fonctionnel et du coup il y a parfois un manque d'attention (motivation?) durant la réunion

[@portoyosh]

Je l'attend avec impatience :)

[@jarod51]

Et par extension, j'ai eu l'expérience de développeurs qui n'étaient pas en phase avec les demandes du PO (et ils avaient raison pour le coup). Cela pose la question du PO qui n'est pas à la hauteur des canons actuels du développement (Non ! Pas 25 checkbox sur une page et pas de logo qui tourne !) :)

[@jarod51]

Tout à fait OK. Mais là nous faisions face à un PO qui voulait imposer une vision exhaustive : du fonctionnel, à l'ux, en passant par le design. Ca n'était même pas un ancien tech' !

[@franckdelinard8099]

Oui même si vous avez une large expérience technique nous pouvons pas tous connaître comme vous dite il faut ce rattraper sur la direction du produit sans s'étaler sur qui est le plus fort techniquement le but est que le projet avance dans les date line

[@damienlebris7119]

Les digressions techniques apparaissent souvent en poker planning car l'estimation se basent sur la complexité de réalisation pour l'équipe, généralement. On dérive souvent en conception technique pour cela. Dans un autre scrumlife, l'estimation est proposée par rapport à la complexité de tester la fonctionnalité. Ceci permet de rester proche du fonctionnelle. C'est une bonne pratique pour éviter les digressions. En grooming, généralement, les équipes, avec qui j'ai pu travailler, restait sur un partage fonctionnel. C'est une chance. 😄

[@lutaseb]

j aime bien revenir sur tes vidéos, un peu comme le scrum guide d ailleurs. J ai une question justement, quid des refinments ds des équipes qui font que des API, pas d ui, pas grand chose en terme de fonctionnel

[@ScrumLife]

Comment ça pas de fonctionnel ? A quoi sert cette API ? Une bonne API Rest ça manipule des concepts métiers... Mais évidemment ça n'a rien à voir de la puissance de l'agilité en équipe "fullstack" qui gère tout de bout en bout. Entre une équipe backend qui manipule des vrais concepts mais seulement programmatiquement, et une équipe frontend qui touche au design et au parcours utilisateur mais qui ne gère rien des règles métiers... Ensemble, ça donne autre chose !

[@lutaseb]

@@ScrumLife je parle bien de cela. Ils vont manipuler des concepts métiers mais en terme de nouveautés dans ce qu ils manipulent, ils risquent d avoir fait le tour assez vite, bcp plus qu une équipe fullstack en effet! Du coup je me disais que leur refinment a des chances d aboutir a peu de créativité

[@MrAsteba]

@@lutaseb complètement d'accord. La plupart des tâches sur lesquelles je travaille ont quasiment zéro aspect fonctionnel (du style "mettre à jour linux kernel"). Si l'on enlève les discussions techniques des refinements que je fais avec mes collègues, la réunion prendrait 2 minutes.

[@franckdelinard8099]

L'essentiel est d'avoir une équipe solidaire et techniquement correct forte de proposition sans sortire du projet et rester dans le sujet. J'ai plus tôt une vision direction technique et validation des profils pour un projet hors d'après le scrum master il doit être pilote et pas ce concentrer dans la technique

[@portoyosh]

Très bonne vidéo, qui me parle aussi. J'ai eu l'occasion d'être dans une équipe où nous étions tous des techniciens. Du coup la tentation de partir dans la technique était grande et nous digressions toujours. Du coup ça explique pas mal de choses sur les problèmes que nous avons pu rencontrer :)

[@colaps]

Bonjour Jean-Pierre, +1 pouce vers le haut :) Juste pour faire l'avocat du diable : Est-ce que ces discussions "techniques" ne sont pas nécessaires à la DevTeam pour estimer la complexité des US ? Car, si j'ai bien compris, le "Refinement" consiste à rendre READY les US du prochain sprint et donc à réduire le temps passé en planif. Encore merci pour le partage :) Franck C

[@portoyosh]

Heu, pour autant que je sache, les US sont estimées durant le sprint planning. Le refinement est plutôt là pour parler des fonctionnalités, voir si l'expression du besoin est bonne, si c'est cohérent avec l'existant. À ce moment là les US ne sont pas encore prêtes.

[@colaps]

Bonjour Daniel, Le refinement n'étant pas considéré comme une cérémonie Scrum à part entière, elle n'est pas "obigatoire" => tu as entièrement raison. L'estimation se fera, dans ce cas là, pendant la planif. Si on tiens à respecter les conseils de Schwaber et Sutherland, on peut estimer pendant le refinement ("Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog."). Maintenant, et pour te rejoindre, quelques phrases plus loin, les auteurs disent : "The Scrum Team decides how and when refinement is done" => si ton équipe préfère estimer pendant la planif, cela ne pose aucun problème. Cela dépend surtout de la maturité de l'équipe (SHU, HA ou RI). SHU : j'applique. HA : je comprends et j'adapte sans dénaturer !. RI : je fais "à ma sauce" en conservant la finalité de la pratique initiale. @+ Franck C

[@portoyosh]

J'ai le souvenir tu es un adepte du no estimate. Du coup j'ai du mal à voir, on estime juste pour le pilotage du projet, mais pour la planification du sprint? Une vidéo à ce sujet pour être pas mal :) Je viens de revoir SCRUM Life #7 et effectivement il n'y a pas d'estimations. Du coup je commence à me dire que faire de l'estimation c'est peut-être une forme de pilotage en cycle en V sur une période assez courte.

[@cedricbrajus5887]

Qu'est-ce qu'un "dojo" ?

[@sebastiencunin1648]

D'après Wikipedia, le coding dojo est une rencontre entre plusieurs personnes qui souhaitent travailler sur un défi de programmation de façon collective.

[@MrAsteba]

Cela ne me parle pas vraiment. Je travaille sur des produits très techniques (exemple caméras qui classifient des objets avec des sous-catégories et envoyent les résultats en utilisant une API avec très peu d'interface utilisateur), et les "user stories" sont souvent très très techniques avec 0.1% de fonctionnel (du style "augmenter le taux de classification de 0.1%"). Sans discussions techniques poussées impossible de définir s'il est même possible d'implémenter ce qui est décrit dans une user story. Parfois c'est simplement techniquement impossible.

[@ScrumLife]

J'ai l'impression que c'est parce que ton domaine métier est technique ! De fait, ce n'est pas "rentrer dans la technique" mais bien parler du fonctionnel. Une bonne règle c'est de se demander si on parle la langue de "l'utilisateur" (dans votre cas ce n'est pas l'utilisateur final mais celui qui va intégrer votre solution). Qu'en penses-tu ? -- JP

[@MrAsteba]

@@ScrumLife ok, se placer du point de vue de l'utilisateur est logique pour prioriser des fonctionnalités je suis d'accord. C'est juste compliqué d'avoir ces discussions pour ce genre de produits quand le product owner n'a pas un minimum de background technique (mon PO avait 0 bagage technique).