Bonnes Pratiques de Réunion de Refinement
Conduisez des sessions de refinement de backlog efficaces. Préparez le travail pour les sprints avec des exigences claires, de bonnes estimations et une compréhension partagée.
8 min de lecture
Un bon refinement rend la planification fluide. GitScrum aide les équipes à préparer les éléments de travail pour qu'ils soient prêts à être tirés dans les sprints.
Objectif du Refinement
Pourquoi Raffiner
OBJECTIFS DU REFINEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AVANT REFINEMENT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-456: Améliorer la recherche ││
│ │ ││
│ │ Description: Rendre la recherche meilleure ││
│ │ Estimation: ? ││
│ │ Prête: ❌ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ APRÈS REFINEMENT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-456: Ajouter autocomplétion à la recherche ││
│ │ ││
│ │ Description: ││
│ │ En tant qu'utilisateur, je veux des suggestions ││
│ │ pendant que je tape pour trouver les produits ││
│ │ plus rapidement. ││
│ │ ││
│ │ Critères d'Acceptation: ││
│ │ ☐ Suggestions apparaissent après 3 caractères ││
│ │ ☐ Max 5 suggestions affichées ││
│ │ ☐ Navigation clavier fonctionne ││
│ │ ☐ Fonctionne sur mobile ││
│ │ ││
│ │ Notes Techniques: ││
│ │ • Utiliser l'API recherche existante avec préfixe ││
│ │ • Debounce 300ms ││
│ │ • Cache des requêtes récentes ││
│ │ ││
│ │ Estimation: 5 points ││
│ │ Dépendances: Aucune ││
│ │ Prête: ✅ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RÉSULTAT: L'équipe peut tirer en sprint avec confiance │
└─────────────────────────────────────────────────────────────┘
Définition de Prêt
PRÊTE POUR LE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UNE STORY EST PRÊTE QUAND: │
│ │
│ COMPRISE: │
│ ☐ Besoin utilisateur clair │
│ ☐ L'équipe comprend quoi construire │
│ ☐ Questions répondues ou notées comme hypothèses │
│ │
│ DÉFINIE: │
│ ☐ Critères d'acceptation écrits │
│ ☐ Cas limites identifiés │
│ ☐ Designs disponibles (si travail UI) │
│ │
│ ESTIMÉE: │
│ ☐ Story points assignés │
│ ☐ L'équipe est d'accord sur l'estimation │
│ ☐ Assez petite pour terminer dans le sprint │
│ │
│ INDÉPENDANTE: │
│ ☐ Dépendances identifiées │
│ ☐ Bloqueurs résolus ou planifiés │
│ ☐ Peut être travaillée sans attendre │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SI PAS PRÊTE: │
│ • Ne pas tirer dans le sprint │
│ • Continuer à raffiner │
│ • Ou créer un spike pour investiguer │
└─────────────────────────────────────────────────────────────┘
Structure de la Réunion
Session de Refinement
FORMAT DE RÉUNION DE REFINEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LOGISTIQUE: │
│ Durée: 1-2 heures/semaine │
│ Participants: PO, Équipe Dev, Scrum Master │
│ Fréquence: Hebdomadaire ou deux fois par semaine │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AGENDA: │
│ │
│ 1. REVUE (5 min) │
│ • Vérification rapide du backlog refiné │
│ • Des mises à jour depuis la dernière session ? │
│ │
│ 2. DISCUTER LES STORIES (45-90 min) │
│ Pour chaque story: │
│ • PO présente le besoin utilisateur (2 min) │
│ • L'équipe pose des questions (5-10 min) │
│ • Discuter l'approche technique (5 min) │
│ • Écrire/affiner les critères d'acceptation (5 min) │
│ • Estimer (5 min) │
│ │
│ 3. REVOIR LES DÉPENDANCES (10 min) │
│ • Identifier les blocages potentiels │
│ • Planifier la résolution │
│ │
│ 4. PRIORISER (5 min) │
│ • Confirmer l'ordre du backlog │
│ • Prochains éléments prêts pour le sprint │
└─────────────────────────────────────────────────────────────┘
Techniques de Discussion
Poser les Bonnes Questions
QUESTIONS DE REFINEMENT EFFICACES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ POUR COMPRENDRE LE BESOIN: │
│ • "Qui est l'utilisateur de cette fonctionnalité ?" │
│ • "Quel problème résolvons-nous ?" │
│ • "Comment l'utilisateur fait-il aujourd'hui ?" │
│ • "Comment saurons-nous si c'est réussi ?" │
│ │
│ POUR CLARIFIER LE PÉRIMÈTRE: │
│ • "Qu'est-ce qui est DANS le périmètre ?" │
│ • "Qu'est-ce qui est HORS périmètre ?" │
│ • "Quels sont les cas limites ?" │
│ • "Que se passe-t-il si [scénario] ?" │
│ │
│ POUR L'APPROCHE TECHNIQUE: │
│ • "Comment allons-nous implémenter cela ?" │
│ • "Y a-t-il des risques techniques ?" │
│ • "Avons-nous besoin d'un spike d'abord ?" │
│ • "Quels composants existants pouvons-nous réutiliser ?" │
│ │
│ POUR L'ESTIMATION: │
│ • "C'est similaire à quoi qu'on a déjà fait ?" │
│ • "Qu'est-ce qui rend cela complexe ?" │
│ • "Où est l'incertitude ?" │
└─────────────────────────────────────────────────────────────┘
Estimation
Techniques d'Estimation
ESTIMATION PENDANT LE REFINEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANNING POKER: │
│ │
│ 1. PO présente la story │
│ 2. Discussion des questions │
│ 3. Chacun choisit une carte (simultanément) │
│ 4. Révéler les cartes │
│ 5. Si écart: discuter haut/bas │
│ 6. Revoter si nécessaire │
│ 7. Consensus ou moyenne │
│ │
│ SÉRIE DE FIBONACCI: │
│ 1, 2, 3, 5, 8, 13, 21... │
│ │
│ • 1-3: Petit, bien compris │
│ • 5-8: Moyen, quelques inconnues │
│ • 13+: Grand, devrait être découpé │
│ │
│ ESTIMATION RELATIVE: │
│ │
│ "Est-ce plus grand, plus petit ou similaire │
│ à [story de référence] ?" │
│ │
│ Utiliser des stories passées comme ancres: │
│ • Story A = 3 points (notre référence "petit") │
│ • Story B = 8 points (notre référence "moyen") │
│ • Cette nouvelle story est entre A et B → 5 points │
└─────────────────────────────────────────────────────────────┘
Découpage des Stories
Quand et Comment Découper
DÉCOUPAGE DE STORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INDICATEURS QU'UNE STORY EST TROP GRANDE: │
│ │
│ • Estimation > 8 points │
│ • "Ça dépend de beaucoup de choses" │
│ • Difficile de décrire les critères d'acceptation │
│ • Discussions qui s'éternisent │
│ │
│ TECHNIQUES DE DÉCOUPAGE: │
│ │
│ PAR WORKFLOW: │
│ Grande: "Gérer les commandes" │
│ → Petite 1: "Créer une commande" │
│ → Petite 2: "Voir une commande" │
│ → Petite 3: "Annuler une commande" │
│ │
│ PAR VARIATION: │
│ Grande: "Paiement" │
│ → Petite 1: "Paiement par carte" │
│ → Petite 2: "Paiement PayPal" │
│ → Petite 3: "Paiement en plusieurs fois" │
│ │
│ PAR RÈGLE MÉTIER: │
│ Grande: "Calcul de prix" │
│ → Petite 1: "Prix de base" │
│ → Petite 2: "Réductions" │
│ → Petite 3: "Taxes" │
│ │
│ PAR PLATEFORME: │
│ Grande: "Notification" │
│ → Petite 1: "Notification email" │
│ → Petite 2: "Notification push mobile" │
│ → Petite 3: "Notification in-app" │
└─────────────────────────────────────────────────────────────┘
Préparation par le PO
Avant le Refinement
PRÉPARATION DU PRODUCT OWNER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ POUR CHAQUE STORY À RAFFINER: │
│ │
│ □ Besoin utilisateur clairement articulé │
│ □ Contexte business fourni │
│ □ Critères d'acceptation initiaux rédigés │
│ □ Maquettes/designs prêts (si applicable) │
│ □ Questions anticipées préparées │
│ □ Priorité relative déterminée │
│ │
│ INFORMATIONS À PARTAGER: │
│ │
│ • Pourquoi cette fonctionnalité maintenant ? │
│ • Impact attendu sur les utilisateurs │
│ • Métriques de succès │
│ • Contraintes ou deadlines │
│ • Dépendances connues │
│ │
│ ERREURS À ÉVITER: │
│ │
│ ✗ Stories trop vagues │
│ ✗ Pas de contexte │
│ ✗ Prescrire la solution technique │
│ ✗ Trop de stories sans préparation │
└─────────────────────────────────────────────────────────────┘
Refinement avec GitScrum
Fonctionnalités de Support
GitScrum supporte le refinement avec :
Gestion du Backlog:
- Ordre de priorité visuel
- Statut "prêt" sur les stories
- Champs personnalisés pour les critères
- Champs de story points
- Historique des estimations
- Comparaison avec des stories similaires
- Commentaires sur les stories
- Mentions pour les questions
- Historique des discussions
- PO prépare les stories avant
- Équipe ajoute des questions
- Discussion préliminaire en commentaires
- Session synchrone plus efficace