Découvrez toute la communauté Scrum Life ! 👉 sl.run/nPjYVm
@lisedelemarreld2 жыл бұрын
topissime cette video, tres tres bien expliqué et vraiment tres utile quand on commence, merci bcp de l'avoir mis ICI en accessible
@ScrumLife2 жыл бұрын
Merci Lyz ! est-ce que tu penses essayer l'atelier ? Tu en attends quoi ? -- Constantin
@fredericdutin47973 жыл бұрын
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 🙋
@ScrumLife3 жыл бұрын
Salut Frédéric et merci ! Peux-tu nous en dire plus sur ton expérience avec le No Estimates ?
@fredericdutin47973 жыл бұрын
@@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
@ScrumLife3 жыл бұрын
Top ! ! ! Merci du retour et partage. Comment avez-vous mesuré le ROI sur les estimations ?
@kevindalton18793 жыл бұрын
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" !
@ScrumLife3 жыл бұрын
Attends de voir l'épisode qui sort demain, 13h !!!
@thierrycagnin44063 жыл бұрын
Bien vu, très intéressant, parce qu'il y a du vécu derrière. Bravo les gars !
@ScrumLife3 жыл бұрын
Merci ! ! ! Qu'est-ce que tu retiens comme élément fort de cette vidéo ?
@johannlamaury56813 жыл бұрын
Excellente vidéo, bravo et merci !
@ScrumLife3 жыл бұрын
Merci Johann, es-tu prêt à tenter l'atelier dans ton contexte ?
@ExochassE73 жыл бұрын
Super vidéo ! je ne l'ai pas encore regardé mais elle me semble déjà très très pertinente et intéressante !
@ScrumLife3 жыл бұрын
😁 Pense à regarder la vidéo quand même ! Et à nous dire ce que tu en penses ensuite 😊
@jdassonval3 жыл бұрын
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).
@ScrumLife3 жыл бұрын
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 ?
@kalf20003 жыл бұрын
Encore un super épisode ! Merci à vous ! :)
@ScrumLife3 жыл бұрын
Avec plaisir ! Qu'est-ce que tu en retires tout particulièrement ? Quels sont tes "take-aways" ?
@kalf20003 жыл бұрын
@@ScrumLife définir l'objectif de sprint avant de le remplir. J'en parle de suite à mon PO ! 😁
@ScrumLife3 жыл бұрын
Tu peux peut-être accompagner ton PO dans cette démarche ?
@kalf20003 жыл бұрын
@@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. 😉
@ScrumLife3 жыл бұрын
@@kalf2000 On en a beaucoup parlé pendant le Live : tout dépend de ce qu'on définit par "valeur".
@kessasidounia89203 жыл бұрын
super la vidéo :)
@ScrumLife3 жыл бұрын
Merci ! Qu'est-ce que tu as le plus apprécié dans cette vidéo ? -- JP
@rocketeer37083 жыл бұрын
Question : que proposez-vous si votre client vous demande un budget et un planning ? Vous lancer un XTrem Quotation?
@ScrumLife3 жыл бұрын
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
@rocketeer37083 жыл бұрын
@@ScrumLife merci Constantin 🙏 pour ta réponse rapide et le lien associé. C’est éclairant ! Bravo pour la qualité de vos contenus 👍
@ETH-kh9bf5 ай бұрын
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 ?
@ScrumLife5 ай бұрын
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
@ScrumLife18 күн бұрын
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
@chuibete3 жыл бұрын
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
@ScrumLife3 жыл бұрын
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
@chuibete3 жыл бұрын
@@ScrumLife D accord, merci beaucoup :)
@ScrumLife3 жыл бұрын
@@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
@chuibete3 жыл бұрын
@@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