Outil Agile Scrum : définir l'OBJECTIF de SPRINT / SPRINT GOAL -- Scrum Life donne sa checklist ! ✅

[@Cancrelat_et_Freluquet]

Merci pour vos vidéos qualitatives ! Je progresse dans mon rôle de SM grâce à vous !

[@ScrumLife]

Salut @Cancrelat_et_Freluquet, Merci beaucoup pour ton retour super motivant ! 🥳 Ça fait vraiment plaisir de savoir que nos vidéos t'aident à progresser dans ton rôle de Scrum Master. Y a-t-il un sujet en particulier que tu aimerais qu'on aborde dans nos prochaines vidéos ? 🚀 Hâte de te lire ! Robin de Scrum Life

[@TipTop712]

Très bonne vidéo, merci !

[@YvesWeber]

Excellente vidéo qui mériterait bien plus de pouces bleus ! merci pour toutes les bonnes idées

[@ScrumLife]

Merci à toi ! Quel est ton conseil préféré ? -- JP

[@YvesWeber]

@@ScrumLife Hello JP, l'astuce sur la visualisation du BD avec l'objectif remplaçant le zéro

[@ScrumLife]

Top ! Si tu mets ça en place, reviens nous raconter ce que ça a donné ! 💪💪 -- JP

[@277YOYO]

Très bonne vidéo ! Dans un contexte de refonte d'une application où on a clairement des product goal mais pas réellement d'objectif de sprint qui soit vraiment motivant. D'autant plus que 80 % des fonctionnalités existe déjà donc ça serait un peu "simuler" le fait que il y ait vraiment un objectif court terme. La solution que j'ai mis en place en attendant c'est d'avoir des objectifs "d'équipe" dans le sprint type : mise en place de pairing sur une techno, plus de goulot d'étranglement dans la colonne merge request, pas plus de 30 min sans demander de l'aide en cas de problème etc...

[@ScrumLife]

Merci Yahann pour le compliment. Effectivement dans le cas d'une refonte c'est plus compliqué, mais pas impossible, par exemple, on peut parfois essayer de tourner les objectifs par rapport à l'objectif de la refonte justement. Pourquoi faites-vous cette refonte ? Dans quel but ? Car si c'est pour refaire exactement pareil, ça serait bizarre, il y a surement une vraie volonté derrière. Qu'en dis-tu ? -- Constantin

[@277YOYO]

@@ScrumLife c'est peut être plus compliqué que une simple refonte a vrai dire. C'est plutôt la fusion de 3 applications vendeurs qui deviennent obsolètes et qui , du fait de leur division, augmente le temps de réalisation d'une vente. Peut être pourrais je partir des points de douleurs remonté par les utilisateurs pour identifier les fonctionnalités "clés" dans mon backlog et en dégager des objectifs ?

[@bayahamidi6343]

Super vidéo, merci 🙂 je rencontre cette problématique de définir LE sprint goal (un seul et unique), notamment car, pour des raisons budgétaires, mon organisation a fait une équipe qui travaillent sur 2 outils qui n'ont rien à voir ensemble, si ce n'est une petite dépendance, mais fondamentalement rien, et donc des fois je me retrouve à définir 2 objectifs de sprint, un pour le premier outil et l'autre pour le second, mais ce n'est pas bon, donc là j'essaie de fixer un seul objectif cohérent, et lors du sprint planning on voit qu'on peut faire entrer d'autres tâches qui n'ont rien à voir avec le sprint goal, ce n'est pas toujours simple 😕

[@ScrumLife]

Bonjour et merci pour ton commentaire ! A mon sens, j’aime bien définir le sprint goal en me plaçant du point de vue utilisateur. Ce que l’équipe va lui apporter sur le sprint. Du coup, si tu as une équipe qui travaille sur deux produits différents je suppose que les utilisateurs de ces produits sont eux aussi différents ? Si oui, formuler deux sprint goals me semble « malheureusement » une bonne solution. Robin

[@4sstylz]

Salut, je cherche un vieux live désespérément qui listait 3 manières de faire un sprints planning : - Par capacité (le moins bon) - etc etc Est-ce que quelqu'un aurait le lien svp ou à défaut la liste des 3 manières nommées ? Merci beaucoup !

[@emmanuelleveque7657]

C'est tellement évident et pourtant je n'y ai jamais penser; l'affichage du sprint goal en gros, grand, gras dans l'espace de l'équipe. Une idée de comment le rendre bien visible en remote?

[@ScrumLife]

Salut Emmanuel, merci ! Demande-toi où l'équipe passe son temps, quel est son "foyer". Pourquoi pas l'épingler en gras dans le canal Slack de l'équipe par exemple ? -- JP

[@m.hamcho5575]

Dans la partie "Avoir un Sprint Goal qui concerne TOUTE l’équipe", à la minute 7:40, Constantin propose de "faire 2 équipes" si le problème cité arrive constamment, "chaque équipe aura son objectif par rapport à ses compétences et son contexte". A vrai dire, j'ai été un peu "choqué" par cette "solution". Scinder l'équipe en 2 n'est pas Scrum, puis, avoir 2 objectifs, pareil, on sort des pratiques et même des règles du Scrum Guide... Est-ce que Constantin voulait parler de la pratique de travail en essaims ? Si tel est le cas, cela ressemble justement à du pair-programming ! Merci de m''expliquer le point de vue.

[@ScrumLife]

Salut M. Hamcho ! "Scinder l'équipe en 2 n'est pas Scrum" pourquoi tu penses que ça ne serait pas Scrum ? "avoir 2 objectifs on sort des pratiques et même des règles du Scrum Guide" pour une seule équipe oui, mais ça n'aurait pas de sens d'avoir le même objectif exactement pour 2 équipes différentes (même si, sur le même produit, leurs objectifs respectifs seraient bien des étapes différentes pour atteindre un même Product Goal). Donc, ce que je veux dire dans la vidéo et ici, c'est que "le produit" n'a qu'un seul objectif, l'objectif produit (Product Goal), mais là la vidéo parle du Sprint Goal, et donc le Sprint Goal d'une équipe doit concerner TOUTE l'équipe en effet. Si on se retrouve avec 2 groupes dans l'équipe, avec des focus différentes, on a donc, de fait, 2 équipes et il faut mieux l'acter, car pour moi cela fait parti de la définition d'une équipe : c'est un groupe de personnes œuvrant dans un objectif commun. Est-ce plus clair ainsi ? T'en dis quoi ? -- Constantin