Gérer le Refinement du Backlog Sprint

Objectifs du Refinement

Processus de Refinement

WORKFLOW REFINEMENT BACKLOG

AVANT SESSION (Product Owner + Tech Lead):
┌─────────────────────────────────────────────────┐
│  1. Revoir les demandes entrantes               │
│  2. Rédiger user stories avec critères acceptation│
│  3. Identifier items nécessitant input technique│
│  4. Pré-prioriser items à discuter              │
│  5. Signaler items avec dépendances ou risques  │
│                                                 │
│  Temps: 1-2 heures avant session hebdomadaire   │
└─────────────────────────────────────────────────┘
              │
              ▼
SESSION REFINEMENT (Équipe Complète):
┌─────────────────────────────────────────────────┐
│  Durée: 1 heure par semaine                     │
│                                                 │
│  Agenda:                                        │
│  1. Revoir nouveaux items (15 min)              │
│     └── PO présente, équipe pose questions      │
│                                                 │
│  2. Clarifier items existants (20 min)          │
│     └── Répondre questions ouvertes, màj stories│
│                                                 │
│  3. Estimer items prêts (20 min)                │
│     └── Planning poker ou similaire             │
│                                                 │
│  4. Identifier risques/dépendances (5 min)      │
│     └── Signaler pour suivi                     │
└─────────────────────────────────────────────────┘
              │
              ▼
APRÈS SESSION (Continu):
┌─────────────────────────────────────────────────┐
│  1. Mettre à jour stories avec clarifications   │
│  2. Rechercher questions techniques signalées   │
│  3. Résoudre dépendances                        │
│  4. Découper stories si trop grandes            │
│  5. Garder backlog priorisé                     │
└─────────────────────────────────────────────────┘

Definition of Ready

DEFINITION OF READY (DoR)

AVANT D'ENTRER EN SPRINT, L'ITEM DOIT AVOIR:

CLARTÉ:
☐ User story suit le format (En tant que... Je veux... Afin de...)
☐ Critères d'acceptation spécifiques et testables
☐ Designs UI attachés (si applicable)
☐ Approche technique comprise

TAILLE:
☐ Estimé par l'équipe
☐ Peut être complété en 1-3 jours
☐ Si plus grand, découpé en sous-tâches

DÉPENDANCES:
☐ Pas de dépendances bloquantes, OU
☐ Dépendances planifiées pour compléter avant
☐ Dépendances externes ont timeline

PRIORITÉ:
☐ Product Owner a priorisé
☐ Alignement stakeholders confirmé

TESTABILITÉ:
☐ Scénarios de test identifiés
☐ Cas limites documentés

Guide de Dimensionnement

RÉFÉRENCE DIMENSIONNEMENT STORIES

1 POINT - Trivial
┌─────────────────────────────────────────────────┐
│  • Changement de configuration                  │
│  • Mise à jour de texte                         │
│  • Bug simple avec cause connue                 │
│  Temps: < 4 heures                              │
└─────────────────────────────────────────────────┘

2 POINTS - Petit
┌─────────────────────────────────────────────────┐
│  • Ajouter champ à formulaire existant          │
│  • Endpoint API simple                          │
│  • Composant UI basique                         │
│  Temps: 4-8 heures (demi à journée complète)    │
└─────────────────────────────────────────────────┘

3 POINTS - Moyen
┌─────────────────────────────────────────────────┐
│  • Nouvelle feature avec 2-3 composants         │
│  • API avec logique métier                      │
│  • Intégration simple                           │
│  Temps: 1-2 jours                               │
└─────────────────────────────────────────────────┘

5 POINTS - Grand
┌─────────────────────────────────────────────────┐
│  • Feature complexe, plusieurs systèmes         │
│  • Considérer découpage si possible             │
│  Temps: 2-3 jours                               │
└─────────────────────────────────────────────────┘

Solutions Connexes

• Priorisation du Backlog
• Techniques d'Estimation Agile
• Sprint Planning pour Résultats Prévisibles