Bonjour, Dans la dernière partie de la vidéo, vous nous invitez à nous demander "Qui inviter à la sprint review ? Quelles sont les parties prenantes de ce sprint ?" Ça sous entend donc que ces parties prenantes changent d'un sprint à l'autre, c'est bien ça ? J'ai bien compris ?
Bonjour Spip, Ce n'est pas une obligation, mais c'est tout à fait possible oui. En review, il est important de n'inviter que les personnes qui ont un vrai intérêt pour ce qui a été fait dans le sprint. Le danger sinon, c'est ce qu'on appelle la "review fatigue". C'est à dire que si les gens viennent "par défaut" mais n'ont pas d'intérêt dans la réunion.. bah ils vont faire autre chose (lire leurs emails par exemple) et au bout d'un moment, ne plus venir. Et le jour où t'as vraiment besoin d'eux, ils ne viennent pas. En plus, inviter les gens dès le début du sprint, ça permet aussi de les informer qu'on va avoir besoin d'eux PENDANT le sprint pour donner du feedback. Qu'en dis-tu ? -- Constantin
En effet Constantin (@@ScrumLife). Je suis tout à fait d'accord. Surtout si, comme expliqué dans la vidéo "Comment intégrer le feedback de la Sprint Review Meeting ?" (ua-cam.com/video/7Yo4leBZJuM/v-deo.html) on récolte du feedback des parties prenantes tout au long du sprint. Il est en effet important (pour ne pas dire primordial) de savoir qui (dans les parties prenantes) va délivrer ce feedback et ce, dès le sprint planning. Non ? -- Nicolas
Hello ! Si j'ai bien compris, les user stories / taches sont définies lors de cette réunion. Du coup les specs ne sont pas détaillées ? pas estimées ? pas de design ? pas ready ?comment dans ce cas peuvent-elles être intégrées au backlog du sprint ?
Bonsoir mchoug25 ! >Si j'ai bien compris, les user stories / taches sont définies lors de cette réunion. Du coup les specs ne sont pas détaillées ? pas estimées ? pas de design ? pas ready ?comment dans ce cas peuvent-elles être intégrées au backlog du sprint ? De ce que nous avons pu tester et qui fonctionne bien pour améliorer la performance et le produit d'une équipe, les US ne sont pas des fonctionnalités, mais l'expression de besoin, de problèmes, bref, de l'information. Grâce à ces informations, l'équipe va alors concevoir des solutions (fonctionnalités) pendant le sprint planning et pendant tout le sprint si nécessaire. Le détail des specs ? => C'est pendant le planning justement L'estimation => Dans cette vision, ce n'est plus nécessaire, ou alors en découpant assez pour se dire que "c'est faisable", tu peux aller voir on en parle dans ces vidéos : ua-cam.com/video/o5tHT5aHmrA/v-deo.html et ua-cam.com/video/Lwj_NlknJ8w/v-deo.html Le Design ? => Il est fait en partie pendant le planning (les grandes lignes) et ajuster au fil du sprint, en effet dans une approche agile, les designer ne travaillent plus dans leur coin, ils font parti de l'équipe ! Ready ? => On travaille sur ce qui est important, pas sur ce qui est prêt. Si il manque une information, et bien on fait sans, ou une solution temporaire en attendant de l'avoir en se basant sur de la data, des convictions ou juste de l'instinc. Si tu veux en savoir plus, on a une formation dédiée à expliquer et expérimenter tout cela. Ça te dit ? -- Constantin
"Faire au maxime du Planning pendant le Sprint Planning" et pas se conditionner par la planification précédant est très important!! Vraiment outil votre truc, les amis!
J’ai hâte !
Merci pour cette vidéo ! Grâce à vous, je vais pouvoir organiser mon premier sprint planning plus sereinement ...
Super Valérie !
C'est prévu pour quand ? C'est déjà passé ? J'espère que tu reviendras nous tenir au courant :)
-- Constantin
Super intéressant, comme d'habitude ! Une autre vidéo à utiliser auprès des équipes :-)
Merci Cym0ril ! Quelle est l'astuce que tu penses essayer en priorité ?
Bonjour,
Dans la dernière partie de la vidéo, vous nous invitez à nous demander "Qui inviter à la sprint review ? Quelles sont les parties prenantes de ce sprint ?" Ça sous entend donc que ces parties prenantes changent d'un sprint à l'autre, c'est bien ça ? J'ai bien compris ?
Bonjour Spip,
Ce n'est pas une obligation, mais c'est tout à fait possible oui. En review, il est important de n'inviter que les personnes qui ont un vrai intérêt pour ce qui a été fait dans le sprint. Le danger sinon, c'est ce qu'on appelle la "review fatigue". C'est à dire que si les gens viennent "par défaut" mais n'ont pas d'intérêt dans la réunion.. bah ils vont faire autre chose (lire leurs emails par exemple) et au bout d'un moment, ne plus venir. Et le jour où t'as vraiment besoin d'eux, ils ne viennent pas.
En plus, inviter les gens dès le début du sprint, ça permet aussi de les informer qu'on va avoir besoin d'eux PENDANT le sprint pour donner du feedback.
Qu'en dis-tu ?
-- Constantin
En effet Constantin (@@ScrumLife). Je suis tout à fait d'accord. Surtout si, comme expliqué dans la vidéo "Comment intégrer le feedback de la Sprint Review Meeting ?" (ua-cam.com/video/7Yo4leBZJuM/v-deo.html) on récolte du feedback des parties prenantes tout au long du sprint. Il est en effet important (pour ne pas dire primordial) de savoir qui (dans les parties prenantes) va délivrer ce feedback et ce, dès le sprint planning. Non ?
-- Nicolas
Hello ! Si j'ai bien compris, les user stories / taches sont définies lors de cette réunion. Du coup les specs ne sont pas détaillées ? pas estimées ? pas de design ? pas ready ?comment dans ce cas peuvent-elles être intégrées au backlog du sprint ?
Bonsoir mchoug25 !
>Si j'ai bien compris, les user stories / taches sont définies lors de cette réunion. Du coup les specs ne sont pas détaillées ? pas estimées ? pas de design ? pas ready ?comment dans ce cas peuvent-elles être intégrées au backlog du sprint ?
De ce que nous avons pu tester et qui fonctionne bien pour améliorer la performance et le produit d'une équipe, les US ne sont pas des fonctionnalités, mais l'expression de besoin, de problèmes, bref, de l'information.
Grâce à ces informations, l'équipe va alors concevoir des solutions (fonctionnalités) pendant le sprint planning et pendant tout le sprint si nécessaire.
Le détail des specs ? => C'est pendant le planning justement
L'estimation => Dans cette vision, ce n'est plus nécessaire, ou alors en découpant assez pour se dire que "c'est faisable", tu peux aller voir on en parle dans ces vidéos : ua-cam.com/video/o5tHT5aHmrA/v-deo.html et ua-cam.com/video/Lwj_NlknJ8w/v-deo.html
Le Design ? => Il est fait en partie pendant le planning (les grandes lignes) et ajuster au fil du sprint, en effet dans une approche agile, les designer ne travaillent plus dans leur coin, ils font parti de l'équipe !
Ready ? => On travaille sur ce qui est important, pas sur ce qui est prêt. Si il manque une information, et bien on fait sans, ou une solution temporaire en attendant de l'avoir en se basant sur de la data, des convictions ou juste de l'instinc.
Si tu veux en savoir plus, on a une formation dédiée à expliquer et expérimenter tout cela. Ça te dit ?
-- Constantin
"Faire au maxime du Planning pendant le Sprint Planning" et pas se conditionner par la planification précédant est très important!! Vraiment outil votre truc, les amis!
Merci !!! As-tu essayé ça ? Ca se passe comment dans ton équipe ?
-- JP