"On doit réserver du temps pour préparer la démo" - Scrum Life 27

🎁 Le guide du Scrum Master compétent 👉 sl.run/4hwWOn
"La Revue d'Itération ça se prépare" -- ah oui, vraiment ?
Je vous propose de faire le tour des raisons qu'évoquent la plupart des équipes pour justifier de prendre beaucoup de temps pour préparer leurs Revues d'Itération, et de voir pourquoi cela adresse en fait un faux problème !
💜️ La communauté Scrum Life 👉 sl.run/f4qXAz
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
Scrum Life 9 sur la Revue d'Itération : • La Revue d'itération, ...
Scrum Life 4 à propos du Definition of Done : • Le Definition of Done ...
Scrum Life 6 à propos de la Rétrospective : • La Rétrospective - Scr...
Scrum Life 5 à propos du Definition of Ready : • Le Definition of Ready...

[@ScrumLife]

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

[@isabellel.5960]

Tes vidéos nous amènent à nous challenger. Bravo et merci pour ça !

[@ScrumLife]

Avec plaisir ! Qu'est-ce que tu retiens en particulier de cette vidéo ? -- JP

[@Sephor38]

sur mon projet qui regroupe plusieurs équipes, on fait un powerpoint d'une diapo par équipe pour lister les features et intégrer des graphiques extrait de Jira pour le traitement des bugs. ça permet d'avoir un support regroupant le travail des différentes équipes. Jira n'étant pas toujours lisible. On ajoute beaucoup d'explication à l'oral en plus des démos Sinon on fige la plateforme 24h avant afin de ne pas risquer la casser pour les démos

[@gazza854]

Merci pour cette vidéo, très instructive sur le pourquoi et le comment d'un Sprint Review. Un bémol sur la forme : les passages "attitudes à déconseiller / ne pas faire" ne sont pas toujours très distincts des passages "conseils / bonnes pratiques" ; mis à part le filtre grisé ... Il faudrait ajouter un symbole plus explicite : peut-être un panneau "attention" ou une croix rouge, et/ou un "tick" vert lorsque vous énoncez une bonne pratique.

[@lidldedl]

De notre côté, on prévoit toujours une journée pour préparer la démo. En effet, on est fortement dépendant d'autres équipes qui livrent très rarement, donc on doit faire des bouchonnages dans notre code pour la démo, sinon on ne peut rien montrer. Le problème, c'est qu'on ne sait qu'en fin de sprint si les équipes auront livré leur correction ou pas car elles n'ont pas de planning, et actuellement nous n'avons aucun levier pour changer leur façon de faire. Et les environnements sont assez instables, et malheureusement, on n'a peu de garantie de dispo et aucun engagement des équipes qui les gèrent.

[@huguespeccatte1532]

De notre côté, nous prenons du temps. Il s'agit de projets souvent techniques (API, outils en lignes de commandes), et cela nous aide donc à ne pas tâtonner pour trouver le fonctionnement exact (ce qui est, je pense, moins le cas avec une interface graphique, car souvent plus intuitive). Mais nous ne prenons pas ce temps en fin de sprint, plutôt en fin de story, en demandant l'écriture d'un scénario. Nous avons constaté que l'investissement durant le sprint n'est pas vraiment plus important, car le scénario en question a déjà été joué pour vérifier que cela fonctionne. Il s'agit donc essentiellement de le décrire et donner les commandes. Aujourd'hui, nous intégrons ce scénario directement dans notre outil scrum (icescrum, dans les commentaires de la story). En essayant de prendre du recul, on pourrait imaginer le documenter ailleurs. Mais le fait d'avoir les scénarios directement dans notre outil nous permet de tout centraliser pour la review, et donc aussi limiter le temps qu'elle nous prend.

[@colaps]

Non mais Jean-Pierre, tu es fou ! Plus de slides !? J'ai un doctorat es-Powerpoint ! Qu'est-ce que je vais faire moi maintenant ? Plus sérieusement, 100 % en phase : La review se prépare un petit peu avant le jour J mais surtout lors de la rétrospective précédente ! Si la démo (qui n'est qu'une petite partie de la Sprint Review !) ne se passe pas bien, c'est tout à fait l'occasion de se lancer dans un 5 Pourquoi lors de la retro suivante, de modifier le DOD et/ou d'identifier des actions correctives à faire pendant le Sprint qui arrive ! Merci pour la vidéo et bon rétablissement. FranckC

[@tinico17]

J'irai même un peu plus loin en disant que l'utilisation des Slides est souvent liée à un mauvais choix qu'on essaye de justifier :) Et bien sûr, on en est conscient et on ne veut surtout pas un Feedback qui nous le dirait :)

[@lorenzodelpais6962]

J'en peux plus tellement cette video était truculente. Beau travail. Merci :-)

[@sanaar1150]

C'est vrai que j'ai souvent vu (et j'en vois encore) des slides dans les sprint reviews, mais c'est vrai que ce n'est pas le but. Cela fait plus de sens quand on revient à la définition du scrum guide plutôt que d'être en mode demo et prez. C'est avant tout une réunion de travail et de Inspect and Adapt.

[@TomCHAPUIS]

merci :)

[@lutaseb]

oui je suis tout a faire d accord sur la perte du temps, surtout qu au final ça fait doublon avec la démo elle meme. Par contre, quid de "l explication" de ce qui a été fait? Pour etre plus clair, tu as une story ou apres avoir appuyé sur un bouton , il se passe un paquet des controles, des validations, des transformations sur des serveurs super chiadés de skynet (qu on ne voit pas)... C est un peu étrange non pour le client de voir que t as passé 2 semaines pour un clic sur un bouton :) ?

[@jaal75]

Nous on fait des slides car on travail sur des projets de recherche de développement, des infra etc… on a pas grand chose à montrer à part des lignes de codes et des schémas. En plus les slides permettent de garder un historique de ce qui est présenter en revue. Sur jira retourner dans les sprint c’est pas hyper simple à lire et pas possible d ajouter les explications qu on y met dans les slides

[@ScrumLife]

Intéressant, mais du coup, qui sont vos utilisateurs ? -- Constantin