J'aime bien parler en amont du Sprint Planning de "l'intention business" du PO ( je suis d'accord avec JP on ne peux pas faire émerger du sens à partir de détails) et demander à la fin de synthétiser après toutes les négos l'Obj de Sprint correspondant car sinon on pourrait avoir l'impression que le match est fait à l'avance aussi. La difficulté qu'on les équipes à définir un objectif de Sprint est bine souvent lié à l'incapacité d'avoir un product backlog ordonné en tranche de valeur.
Heilo les gars ! Même si vous n’atteignez pas les 100 likes, avoir votre avis sur le scrum board m’intéresse beaucoup 🙏🏻😜 J’en profite pour vous remercier sincèrement pour votre travail de qualité qui aide beaucoup la communauté agile francophone à n’en pas douter 😊
Je pense que définir un objectif de sprint est certainement une des plus grosses difficultés des équipes. On veut en effet souvent se dire : j'ai traité telle US et telle autre, quitte à reformuler pour indiquer le métier. Mais dans le même temps, de mon expérience, les équipes sont rarement aidées par le PO/client et le backlog, l'architecture de l'application, la taille du sprint, etc. A nous, scrum master, coach, agiliste convaincu, d'essayer de ramener le sujet régulièrement et de convaincre / proposer par des questions. Merci pour cette vidéo et plus que 18 pouces bleus !
Super l'idée pour le board on attend la vidéo alors 😁 merci pour les astuces sprint planning. Je me rends compte que quand nous étions "en scrum" dans ma société il nous a manqué cela la prise en compte des éléments extérieurs : absences, indisponibilité... C'est ce que veut finalement remettre ma société à travers l'implémentation de SAFE. Le contexte est différent aussi le PO est plus impliqué maintenant dans la plannification...
Et donc : je sors de 2 jours de formation Scrum Master avec Constantin. Autant dire que c'était complètement Bad Ass! Je sens bien que Scrum Life va m'aider dans mes futures missions de coach!!
On en revient toujours au même problème que je constate malheureusement dans beaucoup d'équipe : Définir un objectif de sprint. C'est la base de scrum, mais je tombe souvent sur les mêmes questions/remarques : - On ne peut pas tous être sur le même sujet en même temps, on va se marcher dessus - Et qu'est-ce qu'on fait des petites US qui traînent (comment le dis si bien JP) souvent on en a plein. Par exemple, le consultant a besoin qu'on puisse faire ça sur le module A, un autre consultant voudrait bien qu'on puisse paramétrer ça sur le module B et les HotLiners aimeraient bien avoir plus d'info dans les logs sur le module C. Et bien sûre, tout ça pour la fin d'itération. Ces petites US qui ensemble prennent tout le temps de l'équipe. Bref, un bon sujet. Merci pour vos retours d’expériences, c'était très intéressant.
Si je comprend bien, tu sembles évoquer des "petites US" techniques. Si elles traînent, est ce qu'elles sont toujours utiles ? Pour savoir si elles sont utiles, pouvez vous définir la valeur qu'elles apportent au produit ? Est ce qu'elles sont rédigées de manière fonctionnelle (En tant que ... quand je fais tel chose il se passe tel chose afin de ... ) ? Concernant "On ne peut pas tous être sur le même sujet en même temps, on va se marcher dessus". Est ce que le code permet de travailler sur différentes parties de l'application sans se marcher dessus ? Est ce que l'US incriminée est découpée assez finement ? Dans un autre registre, est ce que l'équipe a des pratiques qui favorise l'appropriation collective du code (design review, pair programming, code review etc...) ?
Ce n'est pas de la dette technique mais le reste du JIT. Sur certaines fonctionnalités qui sont très grosses, l'équipe s'arrête sur les besoins actuels sans allez sur les besoins probables futures (YAGNI) pour deux raisons : - On n'est pas sûre que ces besoins serons encore présent plus tard. - On n'est pas sûre de l'exactitude du besoin Une fois installé, ça répond à tous les besoins. Par contre, il est fréquent que les consultants aient des demandes hors du scope initiale et c'est souvent une ou deux demandes par dossier. Donc c'est bien des US non techniques qui peuvent prendre d'une partie de l'Itération à la moitié. Donc, si on doit avancer en même temps sur plusieurs US de ce type et sur une fonctionnalité, on perd le focus. Merci pour vos réponses, ça me force à prendre du recul sur le sujet et je vois mieux les choses. A mon sens deux possibilités : - Soit ce problème est récurent et donc, il est légitime de se demander si Scrum est bien paramétré ou adéquat à l'équipe (Réduire la taille des sprints, passer sur du Kanban). - Soit on arrive à regrouper ces demandes pour les faire passez en paquet.
Est ce que la formulation de "quel est l'objectif du sprint ?" ne pourrait pas être "A l'issue du sprint, quel incrément va apporter le plus de valeur au client ?" ?
Bonjour Constatin et merci pour cette vidéo . Lorsque vous dites à 6:28 « Qu’est-ce qu’on doit faire pour s’améliorer tout de suite? » vous parlez des process ? J’avais beaucoup plus l’impression qu’on inspecte et traite les process uniquement dans la rétrospective ou je me trompe ?
Salut ! On parle des actions de rétro, de comment les mettre en oeuvre, immédiatement dès les premiers jours du sprint, sans attendre. On parle donc des actions identifiés pendant la rétro précédente, qui précède donc le sprint planning. Après, même si la rétrospective est le moment roi pour parler de process, il ne faut pas la considérer comme le seul et unique moment : si on voit matière à amélioration, il faut le faire sans attendre la rétro ! Est-ce plus clair ainsi ? -- JP
Sprint planning qui se transforme en backlog grooming... Daily meeting qui se transforme en Sprint planning... Rétrospective oubliée... Backlog inexistant... À quoi servent les différents outils agiles? De quoi parle-t'on pendant les différents rituels ? Est-ce qu'un SM peut (doit?) intervenir dans une situation où l'équipe ne maîtrise pas les concepts agiles ?
Bonjour Kamuka. Dans la vraie vie comme dans Scrum, il est bien plus efficace que ce soit les développeurs (experts) qui élaborent le sprint backlog, en collaborant avec la ou le PO. Mais ce sont les développeurs qui ont le dernier mot puisque c’est leur plan pour atteindre l’objectif. Qu’en penses-tu ? - Constantin
@@ScrumLife Merci Constantin pour ta réponse. Je commence dans le monde Scrum. Je suis dans mon premier projet en tant que SM, et c'est le PO qui fait le sprint backlog. Il donne l'objectif du sprint lors du sprint planning mais il profite pour décliner les tasks sur le sprint planning.
Salut @chrisc.4671, Merci pour ton retour ! On essaie toujours de rendre nos vidéos à la fois instructives et accessibles. Peut-être pourrais-tu nous en dire plus sur ce que tu attends des prochaines vidéos ? Ton retour peut nous aider à nous améliorer et offrir du contenu encore plus pertinent pour la communauté. Quel sujet aimerais-tu voir abordé prochainement ? Robin 🧑💻🚀
Découvrez toute la communauté Scrum Life ! 👉 sl.run/toP0WD
Cette poupée a des compétences en pédagogie incroyables
J'aime bien parler en amont du Sprint Planning de "l'intention business" du PO ( je suis d'accord avec JP on ne peux pas faire émerger du sens à partir de détails) et demander à la fin de synthétiser après toutes les négos l'Obj de Sprint correspondant car sinon on pourrait avoir l'impression que le match est fait à l'avance aussi. La difficulté qu'on les équipes à définir un objectif de Sprint est bine souvent lié à l'incapacité d'avoir un product backlog ordonné en tranche de valeur.
Sympa Les 4 Accords Toltèques en arrière-plan ;)
Heilo les gars !
Même si vous n’atteignez pas les 100 likes, avoir votre avis sur le scrum board m’intéresse beaucoup 🙏🏻😜
J’en profite pour vous remercier sincèrement pour votre travail de qualité qui aide beaucoup la communauté agile francophone à n’en pas douter 😊
C'est bon ... on est à 100 ... j'attends l'épisode avec impatience !!!
Va falloir qu'on assure maintenant !
@@cog_g à150like %
@@@@qqqqq@q@qqqqq@@@qqq@
Je pense que définir un objectif de sprint est certainement une des plus grosses difficultés des équipes. On veut en effet souvent se dire : j'ai traité telle US et telle autre, quitte à reformuler pour indiquer le métier.
Mais dans le même temps, de mon expérience, les équipes sont rarement aidées par le PO/client et le backlog, l'architecture de l'application, la taille du sprint, etc.
A nous, scrum master, coach, agiliste convaincu, d'essayer de ramener le sujet régulièrement et de convaincre / proposer par des questions.
Merci pour cette vidéo et plus que 18 pouces bleus !
Les 100 pouces sont bien atteints !! Good job :) Hate de voir cette vidéo promise!
Super l'idée pour le board on attend la vidéo alors 😁 merci pour les astuces sprint planning. Je me rends compte que quand nous étions "en scrum" dans ma société il nous a manqué cela la prise en compte des éléments extérieurs : absences, indisponibilité... C'est ce que veut finalement remettre ma société à travers l'implémentation de SAFE. Le contexte est différent aussi le PO est plus impliqué maintenant dans la plannification...
Et donc : je sors de 2 jours de formation Scrum Master avec Constantin. Autant dire que c'était complètement Bad Ass!
Je sens bien que Scrum Life va m'aider dans mes futures missions de coach!!
😁 carrément et merci !
Que retiens-tu en particulier de l'épisode ?
-- JP
Merci Avi ! C'était un plaisir de t'avoir lors de la formation, avec de super questions en plus ! :)
-- Const
@@ScrumLife j'ai adoré l'idée d'avoir un plan au sprint planning.
On en revient toujours au même problème que je constate malheureusement dans beaucoup d'équipe : Définir un objectif de sprint. C'est la base de scrum, mais je tombe souvent sur les mêmes questions/remarques :
- On ne peut pas tous être sur le même sujet en même temps, on va se marcher dessus
- Et qu'est-ce qu'on fait des petites US qui traînent (comment le dis si bien JP) souvent on en a plein. Par exemple, le consultant a besoin qu'on puisse faire ça sur le module A, un autre consultant voudrait bien qu'on puisse paramétrer ça sur le module B et les HotLiners aimeraient bien avoir plus d'info dans les logs sur le module C. Et bien sûre, tout ça pour la fin d'itération.
Ces petites US qui ensemble prennent tout le temps de l'équipe.
Bref, un bon sujet.
Merci pour vos retours d’expériences, c'était très intéressant.
Si je comprend bien, tu sembles évoquer des "petites US" techniques.
Si elles traînent, est ce qu'elles sont toujours utiles ? Pour savoir si elles sont utiles, pouvez vous définir la valeur qu'elles apportent au produit ? Est ce qu'elles sont rédigées de manière fonctionnelle (En tant que ... quand je fais tel chose il se passe tel chose afin de ... ) ?
Concernant "On ne peut pas tous être sur le même sujet en même temps, on va se marcher dessus".
Est ce que le code permet de travailler sur différentes parties de l'application sans se marcher dessus ? Est ce que l'US incriminée est découpée assez finement ?
Dans un autre registre, est ce que l'équipe a des pratiques qui favorise l'appropriation collective du code (design review, pair programming, code review etc...) ?
Ce n'est pas de la dette technique mais le reste du JIT. Sur certaines fonctionnalités qui sont très grosses, l'équipe s'arrête sur les besoins actuels sans allez sur les besoins probables futures (YAGNI) pour deux raisons :
- On n'est pas sûre que ces besoins serons encore présent plus tard.
- On n'est pas sûre de l'exactitude du besoin
Une fois installé, ça répond à tous les besoins. Par contre, il est fréquent que les consultants aient des demandes hors du scope initiale et c'est souvent une ou deux demandes par dossier. Donc c'est bien des US non techniques qui peuvent prendre d'une partie de l'Itération à la moitié.
Donc, si on doit avancer en même temps sur plusieurs US de ce type et sur une fonctionnalité, on perd le focus.
Merci pour vos réponses, ça me force à prendre du recul sur le sujet et je vois mieux les choses.
A mon sens deux possibilités :
- Soit ce problème est récurent et donc, il est légitime de se demander si Scrum est bien paramétré ou adéquat à l'équipe (Réduire la taille des sprints, passer sur du Kanban).
- Soit on arrive à regrouper ces demandes pour les faire passez en paquet.
SCRUUUUUM BOOOOOOAAAAAAARRRRDDDD !!!!
👏 Beau sujet !
Hop, j'ai mis mon petit pouce bleu !
Est ce que la formulation de "quel est l'objectif du sprint ?" ne pourrait pas être "A l'issue du sprint, quel incrément va apporter le plus de valeur au client ?" ?
Au final, il est où le lien vers la vidéo qui a été créée à partir des 100 pouces ? Merci en tout cas.
+100 ;)
Bonjour Constatin et merci pour cette vidéo . Lorsque vous dites à 6:28 « Qu’est-ce qu’on doit faire pour s’améliorer tout de suite? » vous parlez des process ? J’avais beaucoup plus l’impression qu’on inspecte et traite les process uniquement dans la rétrospective ou je me trompe ?
Salut ! On parle des actions de rétro, de comment les mettre en oeuvre, immédiatement dès les premiers jours du sprint, sans attendre.
On parle donc des actions identifiés pendant la rétro précédente, qui précède donc le sprint planning.
Après, même si la rétrospective est le moment roi pour parler de process, il ne faut pas la considérer comme le seul et unique moment : si on voit matière à amélioration, il faut le faire sans attendre la rétro !
Est-ce plus clair ainsi ?
-- JP
@@ScrumLife oui c’est parfait , merci.
Et de 100 likes !
Oh oui oh oui :) 99 restants :)
9 pouces bleu manquants :D
Sprint planning qui se transforme en backlog grooming...
Daily meeting qui se transforme en Sprint planning...
Rétrospective oubliée...
Backlog inexistant...
À quoi servent les différents outils agiles? De quoi parle-t'on pendant les différents rituels ?
Est-ce qu'un SM peut (doit?) intervenir dans une situation où l'équipe ne maîtrise pas les concepts agiles ?
Merci pour la vidéo.
Petite question. Dans la vrai vie, qui est celui qui élabore le sprint backlog ? le PO ou l'équipe de développeurs ?
Bonjour Kamuka. Dans la vraie vie comme dans Scrum, il est bien plus efficace que ce soit les développeurs (experts) qui élaborent le sprint backlog, en collaborant avec la ou le PO. Mais ce sont les développeurs qui ont le dernier mot puisque c’est leur plan pour atteindre l’objectif.
Qu’en penses-tu ?
- Constantin
@@ScrumLife Merci Constantin pour ta réponse. Je commence dans le monde Scrum. Je suis dans mon premier projet en tant que SM, et c'est le PO qui fait le sprint backlog. Il donne l'objectif du sprint lors du sprint planning mais il profite pour décliner les tasks sur le sprint planning.
+1 (n'en manque plus que 17 :)
Et voilà les 99 restant 👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍
Les Fréd et Jamy de l'informatique ..Encore plus d€bile
Salut @chrisc.4671,
Merci pour ton retour ! On essaie toujours de rendre nos vidéos à la fois instructives et accessibles. Peut-être pourrais-tu nous en dire plus sur ce que tu attends des prochaines vidéos ? Ton retour peut nous aider à nous améliorer et offrir du contenu encore plus pertinent pour la communauté.
Quel sujet aimerais-tu voir abordé prochainement ?
Robin 🧑💻🚀