La Revue d'itération, bien plus qu'une démo - Scrum Life 9

🎁 Le guide du Scrum Master compétent 👉 sl.run/de2g9v
Dans cet épisode de Scrum Life on fait un retour aux sources sur la Revue d'Itération. C'est bien plus qu'une simple démo ! Toute l'essence, le mindset de Scrum transparait dans cette réunion. J'espère qu'au minimum cette vidéo vous fera réfléchir sur votre propre pratique !
💜️ La communauté Scrum Life 👉 sl.run/4lyeIp
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
Le lien vers la section Sprint Review du Scrum Guide : www.scrumguides...
Les anciens épisodes de Scrum Life que je cite :
Scrum Life 7 sur la planification d'itération : • L'équipe n'arrive pas ...
Scrum Life 4 sur le Definition of Done : • Le Definition of Done ...
Concernant les news :
Mon tout nouveau blog, tout beau tout neuf : jp-lambert.me
Agile Tour Paris, le 29 Novembre 2017 : at2017.agiletou...
Ma session "Une semaine dans ma peau de Scrum Master" est annoncée de 11h15 à 12h00 en salle Prairie !

[@ScrumLife]

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

[@pascalmeunier5646]

Encore une vidéo très enrichissante. Bravo et merci :-) J'aurais juste une petite suggestion: Lors des "jeux de rôle" tu mets un filtre gris. C'est chouette. Ça serait encore plus cool si tu mettais un élément visuel différent pour chaque personnage. Genre un chapeau ou une autre paire de lunette. Ça permettrait qu'au premier coup d'œil on voit qui parle. Si je me rappelle, tu l'as fait pour une autre vidéo. Il faudrait peut-être simplement systématiser ça. En tout cas merci. Je suis l'un de tes plus grands fans :-P

[@aliciamodeste5443]

Je me suis abonnée il y a quelques jours et cette chaine m'aide beaucoup dans mon nouveau métier, cependant je n'ai rien à cette vidéo contrairement aux autres qui sont plutôt claires

[@ScrumLife]

😲 zut alors... Comment peut-on vous aider ? Est-ce dû à la mise en scène d'une Revue de Sprint qui est longue et mal identifiée ? Dites-nous, on ne peut pas vous laisser comme ça !!!

[@mohamedgargouri2162]

Bravo pour la vidéo. je vous encourage à continuer. Ma remarque (que j'espère constructive) est pour la partie "jeux de rôle". A un certain moment je me demandais est ce que vous cherchez à montrer des pratiques non souhaitées et c'était plutôt une démonstration d'un bon déroulement d'un Sprint Review. Pêut être afficher des sous-titrage pour expliquer ce que vous cherchez à véhiculer derrière chaque mise en situation. je réitère mes encouragements :)

[@mohamedgargouri2162]

JP Lambert en effet je viens de le voir sur la #17. Ça aide à bien situer le contexte et comprendre la finalité de chaque mise en situation.

[@mathiaspouessel7937]

Hello JP ! Merci pour toutes tes vidéos, c'est vraiment quelque chose qui manquait sur SCRUM, des exemple et des réponses à des situations concrètes du quotidien. Surtout ne t'arrête pas :) Question concernant la revue : penses-tu qu'il soit pertinent d'afficher les indicateurs (notamment le nombre de points réalisés effectivement pendant l'itération vs le nombre de points planifiés) ? Dans ma société c'est ce qui est fait par la majorité des équipes, mais je me demande si ça n'a pas un effet pervers, qui pousse à chercher à se justifier, ou même à bâcler le travail pour que le maximum de points soit fait, en mettant de côté le definition of done. Car le management sera présent et forcément ça a toute son importance. Merci d'avance pour ta réponse ! et on se verra sûrement au mixIT !

[@kads9159]

Hello Mathias Présenter le nombre de points réalisés n'a pas de sens de mon point de vue. Chaque équipe à son propre référentiel d'estimation et de ce fait, une même UserStorie n'aura pas la même estimation d'une équipe à l'autre. Je l'utilise plus pour mesurer la vélocité de l'équipe d'un Sprint à l'autre mais si il y a des changements de staffing dans l'équipe il faut réajuster également ce KPI.

[@romaingauthier9515]

Hello, je pense que beaucoup de coachs agile (dont scrum life) minimisent l'importance du design et des designers. Demander du feedback après avoir codé, c'est beaucoup trop tard et beaucoup trop cher. Il y a des façons de valider des idées et des design avant de les coder, avec des prototypes, des concierge tests, des interviews, de l'analytics, des fake door test, etc .. . Scrum est vraiment incomplet comme process "produit" et doit couvrir 20-25% maximum de l'activité d'un bon product owner. kzbin.info/www/bejne/oIfFh3iae5xohqc

[@ScrumLife]

Merci pour ce commentaire. En effet, pour le moment, ces aspects ne sont pas assez traités par Scrum Life. 👍

[@galiongr973]

Maam1l

[@sylvainlemang-catel4138]

bravo JP !

[@wazpoki1943]

Ne faut-il pas rappeler l'objectif de l'itération qui peut avoir été oublié par les parties prenantes et qui redonne un sens à ce qui a été fait et indiquer s'il a été atteint ou non pour évoquer les réussites ou les problèmes éventuels?

[@r33iv44x]

Dans la mesure où la revue de sprint ne sert pas à communiquer un statut d'avancement, parler des items non terminés - même si c'est inscrit au Guide Scrum - semble quelque peu contradictoire et d'un intérêt assez discutable, non ? Ce ne sont pas les items inachevés qui vont permettre de collecter des retours fonctionnels. Les passer en revue risque plutôt d'instiller un sentiment de culpabilité chez l'équipe. À mon sens, cet aspect du sprint devrait être abordé en rétrospective.

[@r33iv44x]

Tu le dis toi-même : "[les items inachevés] font partie de l'introspection de l'équipe sur son fonctionnement." Et tu le confirmes ensuite en faisant le lien entre équipe/processus et rétrospective (cf. 3ème paragraphe) . En bref (et en toute logique donc), l'introspection du fonctionnement de l'équipe, qui inclut les items inachevés, a lieu en rétrospective.

[@r33iv44x]

L'inspection en revue de sprint porte sur l'incrément du produit. L'adaptation en revue de sprint porte sur le plan de release et le backlog de produit (priorisation).