Premier Sprint Scrum : L'ATELIER pour créer un BACKLOG produit en 3H ⌛ Une demi-journée suffit !

[@ScrumLife]

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

[@lisedelemarreld]

topissime cette video, tres tres bien expliqué et vraiment tres utile quand on commence, merci bcp de l'avoir mis ICI en accessible

[@ScrumLife]

Merci Lyz ! est-ce que tu penses essayer l'atelier ? Tu en attends quoi ? -- Constantin

[@fredericdutin4797]

Top ! En phase avec JP sur le no estimate et le fait de rester focus sur la vision produit et l'objectif de produire de la valeur un formidable levier de motivation pour toute l'équipe 🙋

[@ScrumLife]

Salut Frédéric et merci ! Peux-tu nous en dire plus sur ton expérience avec le No Estimates ?

[@fredericdutin4797]

@@ScrumLife Oui nous avons comparé le temps consacré au planning poker et le ROI sur des estimations qui restent relatives. Nous calculons notre CAF sur le nombre moyen d'items que nous sommes en mesure d'absorber au fil des sprints et de fait le no estimate retire de la complexité inutile à notre process

[@ScrumLife]

Top ! ! ! Merci du retour et partage. Comment avez-vous mesuré le ROI sur les estimations ?

[@kevindalton1879]

Bravo les gars ! J'adore ! On retrouve vraiment la philosophie du Lean Startup => "On n'a pas eu le résultat attendu mais on a capitalisé du savoir avec un vrai feedback terrain et on sait maintenant où on doit mettre le focus pour apporter de la valeur" !

[@ScrumLife]

Attends de voir l'épisode qui sort demain, 13h !!!

[@thierrycagnin4406]

Bien vu, très intéressant, parce qu'il y a du vécu derrière. Bravo les gars !

[@ScrumLife]

Merci ! ! ! Qu'est-ce que tu retiens comme élément fort de cette vidéo ?

[@johannlamaury5681]

Excellente vidéo, bravo et merci !

[@ScrumLife]

Merci Johann, es-tu prêt à tenter l'atelier dans ton contexte ?

[@ExochassE7]

Super vidéo ! je ne l'ai pas encore regardé mais elle me semble déjà très très pertinente et intéressante !

[@ScrumLife]

😁 Pense à regarder la vidéo quand même ! Et à nous dire ce que tu en penses ensuite 😊

[@jdassonval]

Top, très réaliste (je fais en mode projet et non produit cette approche. On doit ajuster un peu en mode projet mais comme tout, il faut savoir piocher dans des outils/méthodes pour s'adapter au contexte).

[@ScrumLife]

Oui, en effet ! Ce n'était pas notre focus original, mais on doit pouvoir cadrer avec succès un projet avec ce type d'atelier. As-tu d'autres exemples d'ateliers, outils et méthodes que tu utilises ainsi dans ton quotidien ?

[@kalf2000]

Encore un super épisode ! Merci à vous ! :)

[@ScrumLife]

Avec plaisir ! Qu'est-ce que tu en retires tout particulièrement ? Quels sont tes "take-aways" ?

[@kalf2000]

@@ScrumLife définir l'objectif de sprint avant de le remplir. J'en parle de suite à mon PO ! 😁

[@ScrumLife]

Tu peux peut-être accompagner ton PO dans cette démarche ?

[@kalf2000]

@@ScrumLife yes! mais c'est vrai qu'en ce qui concerne notre projet et son contexte, fixer des objectifs qui apporte une vrai valeur utilisateur (au sens fonctionnalité complète pouvant potentiellement être mis en prod) ... C'est compliqué. Généralement il faut à l'équipe plus qu'un sprint pour y arriver. Le concept de product goal est plus simple a appliquer pour nous. Mais on va travailler ça. 😉

[@ScrumLife]

@@kalf2000 On en a beaucoup parlé pendant le Live : tout dépend de ce qu'on définit par "valeur".

[@kessasidounia8920]

super la vidéo :)

[@ScrumLife]

Merci ! Qu'est-ce que tu as le plus apprécié dans cette vidéo ? -- JP

[@rocketeer3708]

Question : que proposez-vous si votre client vous demande un budget et un planning ? Vous lancer un XTrem Quotation?

[@ScrumLife]

Bonjour Martial, vaste et passionnante question. Comme nous le voyons dans la vidéo, nous ne parlons de fonctionnalité qu'au dernier moment, c'est à dire quand on va s'attaquer à un problème/besoin : à ce moment-là, nous allons envisager les fonctionnalités ou solutions qui, nous le pensons, pourraient répondre au problème. Donc, puisque nous ne définissons pas, au début, les fonctionnalités à faire dans X mois, nous ne pourrions baser notre extreme quotation que par rapport aux problèmes identifiés. Et dans ce cas-là, on peut travailler sur un plan qui serait au final, "les objectifs de sprint sur lesquels on va travailler". Je t'envoie vers cette vidéo qui le décrit plus en détail => kzbin.info/www/bejne/ZpCUm5KAotFsgdE - Const

[@rocketeer3708]

@@ScrumLife merci Constantin 🙏 pour ta réponse rapide et le lien associé. C’est éclairant ! Bravo pour la qualité de vos contenus 👍

[@ETH-kh9bf]

Votre recommandation de supprimer l'estimation est séduisante et bien argumentée mais pas facile à vendre. Et surtout se passer du coût comme paramètre d'évaluation de la VALEUR indique qu'on ne parle pas vraiment de VALEUR (rapport entre l'Utilité pour le Business et ce que ça coûte pour l’obtenir). S'il s'agit juste, au premier Sprint, de produire le bootstrap incontournable, se passer d'estimation n'est pas gênant. En revanche s'il s'agit de MAXIMISER la VALEUR entre plusieurs options possibles, alors les coûts me semblent nécessaires pour prioriser la plus rentable (du moins à court terme). Votre proposition de supprimer l'estimation vaut-elle juste pour le 1er Sprint ou tout le temps ?

[@ScrumLife]

Salut, nous nous parlons bien de ne pas faire d’estimation même au-delà des premiers sprints. En effet tu parles de maximiser la valeur en fonction de son estimation, mais rappelons nous que la valeur est déjà une estimation de celle-ci. Donc si tu fais un rapport entre deux nombres plus ou moins fiables, des estimations, des idées en sorte, je ne pense pas que tu devrais baser toute ta stratégie sur ce chiffre final de « ROI » encore plus sujet à l’aléatoire. Ça me semble être un gros risque. - constantin

[@ScrumLife]

Salut @ETH-kh9bf, Merci pour ton commentaire très pertinent ! 😊 Je comprends tout à fait tes points de vue, et il est vrai que supprimer les estimations peut sembler contre-intuitif, surtout lorsqu’il s’agit de maximiser la valeur entre plusieurs options. Cependant, l'idée derrière cette proposition est d'encourager les équipes à adopter une approche davantage basée sur les résultats tangibles et l'impact direct sur l’utilisateur final. Pour répondre à ta question, cette recommandation peut s'appliquer au-delà du premier sprint. L’objectif est de se concentrer sur des livrables réels et évolutifs plutôt que de perdre du temps à estimer, souvent avec une marge d'erreur significative. Enfin, je comprends que cette approche peut être délicate à "vendre". C'est pourquoi il est crucial d'impliquer toutes les parties prenantes dès le début, en leur montrant l’efficacité d'une équipe qui se concentre sur des livraisons fréquentes et de qualité. Et toi, as-tu déjà essayé de réduire les estimations dans tes projets ? Quels ont été les résultats ? On est curieux de connaître ton expérience ! À bientôt, Robin

[@chuibete]

Ok mais on a ecrit des US, on a pas reussi a tout gerer dans le sprints, du coup il en reste. En presentant au client il a dit ok, pour le prochain sprint je voudrais avoir tel valeur en plus Du coup on a des US quiiii vont rester dans le backlog, pendant qu on va travailler sur la nouvelle valeur a ajouter. et ceux tout les sprints, du coup on a un backlog qui augmente, augmente augmente, que faire de toute ces US qui sont descopes et qui, reste importante mais moins prioritaire par demande du client

[@ScrumLife]

Et bien... On le jette ! Un mot d'ordre qui marche bien c'est de se dire : "si c'est important, ça reviendra" -- inutile de noter tout ce qu'on imagine et de faire grossir indéfiniment le backlog. À chaque sprint, on se demande ce qu'il faut faire de plus pertinent. -- JP

[@chuibete]

@@ScrumLife D accord, merci beaucoup :)

[@ScrumLife]

@@chuibete Je complète la réponse de Jean-Pierre en ajoutant que si on ne considère les fonctionnalités que comme des moyens d'atteindre un but (le sprint goal), alors à la fin du sprint la question intéressante n'est pas forcément "avons-nous tout fait ?" mais plutôt, "avons-nous atteint notre but ?" Et si la réponse est oui, alors je préconise plutôt de jeter le reste. Si ce n'est pas le cas, alors je préconise de jeter quand même ce qu'on voulait faire et de se poser 2 questions : "Notre but a-t-il toujours du sens ? Si oui, vu l'état actuel du produit, que nous faut-il pour atteindre notre objectif ?" Peut-être alors que nous reprendrons des fonctionnalités commencées dans le sprint précédent, peut-être pas. Je trouve ça sain de se poser la question. Qu'en dis-tu ? -- Constantin

[@chuibete]

@@ScrumLife Bonjour Constantin Ca fait sens, le probleme avec cette question c est qu elle ne semble pas prendre en compte les NFR, l objectif est atteint, mais il y a des besoins non fonctionnel important, mais effectifement si c est si important ca reviendra