Update agile content - Affinage cheatsheet

src/affinage/first-side/column1.md

@@ -1,30 +1,35 @@
-# Durée
+# Durée / Fréquence
 
-~1 h
-
-# Fréquence
-
-En fonction des besoins   
-Viser une fois par semaine
+- En fonction des besoins, prévoir 1h / semaine pour commencer
 
 # Objectifs
 
-`Avoir la vision dev des besoins`
-`Chiffrer les User Stories
-(optionnel si fait en sprint planning)`
-`Fractionner les US trop grosses`
-`Avoir des propositions techniques`
-`Mûrir les US`
-`Prioriser les US`
+- Avancer dans le mûrissement des US, soit l’établissement des différents points de la Definition Of Ready
+- Confronter la vision fonctionnelle et technique du sujet, le besoin et sa solution
+- Prioriser, purger, trier les US 
 
 # Acteurs
 
-`Scrum Master`
-`Équipe`
-`Product Owner`
-`Parties prenantes`
+- Au moins 1 représentant de l’équipe et de chaque service impacté par la réalisation des US à mûrir 
+- Product Owner, Experts métiers et techniques (données, dev, design), Testeurs… 
+- Scrum Master si besoin
+
+# Rôle du Product Owner
+
+- Clarifier les besoins
+- Assurer la cohérence avec la vision produit
+- Animer l’atelier
+- Arbitrer entre différentes solutions proposées si elles ont un impact sur le périmètre fonctionnel
+
+
+# Definition Of Ready
+La DOR est établie par l’équipe et doit lister l’ensemble des critères que doit vérifier une US pour être considérée comme mûrie / prête à développer.
 
- # Rôle du Product Owner
+Modèle INVEST - une US doit être :
 
-`Clarifier les besoins`
-`Assurer la cohérence avec la vision produit`
+- **I**ndépendante
+- **N**égociable : besoin, règles métier
+- **V**alorisée :  sur une échelle de Valeur Métier
+- **E**stimable : solutions potentielles, complexité, impact 
+- **S**uffisamment simple : risque acceptable
+- **T**estable : critères et scénarios de validation

src/affinage/first-side/column2.md

@@ -1,25 +1,28 @@
 # Deroulé
 
-`Energizer / icebreaker (optionnel)`
-`Explication des US`
-`Discussion autour de chaque US`
-`Clôture`
+US par Us :
+- Présenter les éléments déjà établis (au moins User Voice, valeur métier)
+- Echanger sur un ou plusieurs points de la DOR jusqu’à la clarification
+- Cocher les items de la liste clarifiés
+- S’il reste du temps, passer à l’US suivante
+- Suivant l’avancement et les éléments obtenus, le PO réajuste les priorités et sa vision des prochains sprints
 
 # Entrants
 
-`Definition Of Ready`
-`Backlog Produit (avec US à affiner)`
+- Backlog Produit priorisé
+- DOR
+- PO : Définir le  besoin (modèle User Voice) et la valeur métier de chaque item à mûrir
 
 # Sortants
 
-`Backlog Produit priorisé et mûri`
+- Backlog Produit repriorisé et mûri
 
 # Potentiels problèmes / solutions
 
-`Non disponibilité de tous les acteurs au même moment`
+Acteurs non dispos au même moment ➡️ Spécialiser en plusieurs ateliers au choix : Mûrissement, Priorisation, Analyse technique, Estimation
 
-Séparer en 2 rituels : Mûrissement et Priorisation
+Trop détailler les US ➡️ Se concentrer sur la DOR et détailler le besoin plus que la solution
 
-`Chercher la perfection en sortie de 5h de réunion`
+Réunion trop longue ➡️ Préférer de petites réunions régulières, traiter peu d’US mais terminer leur DOR, spécialiser en plusieurs ateliers au choix 
 
-Préférer de petites réunions régulières afin d'avancer sans chercher à tout finir
+Affinage impactant l’objectif du sprint ➡️ Le temps d’affinage du backlog n’est pas du temps de production et doit être clarifié, par ex pendant le Sprint Planning