8 min lecture • Guide 79 of 877
Gérer les Changements de Périmètre en Cours de Sprint
Les changements de périmètre pendant un sprint sont une réalité, pas un échec. Les marchés évoluent, les priorités changent, et de nouvelles informations émergent. La question n'est pas si le périmètre va changer, mais comment gérer les changements sans détruire la concentration de l'équipe ou les engagements du sprint. GitScrum fournit la structure pour évaluer, communiquer, et intégrer les changements de périmètre tout en protégeant l'intégrité du sprint.
Comprendre l'Impact des Changements de Périmètre
Types de Changements en Cours de Sprint
CATÉGORIES DE CHANGEMENT DE PÉRIMÈTRE:
┌─────────────────────────────────────────────────────────────┐
│ TYPES ET RÉPONSES TYPIQUES │
├─────────────────────────────────────────────────────────────┤
│ │
│ URGENCE (Doit être traitée immédiatement) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemples: ││
│ │ • Panne production affectant utilisateurs ││
│ │ • Vulnérabilité sécurité découverte ││
│ │ • Échéance conformité réglementaire ││
│ │ • Changement exigence légale ││
│ │ ││
│ │ Réponse: Intégrer au sprint immédiatement ││
│ │ Quelque chose d'autre doit sortir ││
│ │ Documenter pourquoi pour rétrospective ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ HAUTE PRIORITÉ (Important mais pas urgence) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemples: ││
│ │ • Problème bloquant client clé ││
│ │ • Nouvelle opportunité business avec échéance ││
│ │ • Dépendance découverte affectant roadmap ││
│ │ ││
│ │ Réponse: Évaluer taille et capacité sprint ││
│ │ Peut-il attendre 3-5 jours prochain sprint? ││
│ │ Sinon, négocier échange périmètre ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AMÉLIORATION (Agréable à avoir) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemples: ││
│ │ • Idée amélioration partie prenante ││
│ │ • Suggestion amélioration UX ││
│ │ • Opportunité rembourser dette technique ││
│ │ ││
│ │ Réponse: Ajouter au backlog, prioriser normalement ││
│ │ Ne pas perturber sprint ││
│ │ Discuter à prochaine planification ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DÉRIVE PÉRIMÈTRE (Expansion fonctionnalité) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemples: ││
│ │ • "Puisque vous y êtes, pourriez-vous aussi..." ││
│ │ • Surenchère sur exigences ││
│ │ • Complexité non découverte émergeant ││
│ │ ││
│ │ Réponse: Séparer périmètre original de l'expansion ││
│ │ Compléter périmètre engagé d'abord ││
│ │ Expansion va au backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Évaluation d'Impact
ÉVALUER L'IMPACT DU CHANGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ MATRICE IMPACT CHANGEMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TAILLE DU CHANGEMENT ││
│ │ Petit Moyen Grand ││
│ │ ┌──────────┬──────────┬──────────┐ ││
│ │ Début │ 🟢 │ 🟢 │ 🟡 │ ││
│ │ (Jour │ Peut │ Échange+ │ Négocier │ ││
│ │ 1-2) │ échanger │ ajuster │ périmètre│ ││
│ │ S ├──────────┼──────────┼──────────┤ ││
│ │ P Milieu│ 🟢 │ 🟡 │ 🔴 │ ││
│ │ R (Jour │ Peut │ Risque │ Prochain │ ││
│ │ I 3-6) │ prudemment│ burndown │ sprint │ ││
│ │ N ├──────────┼──────────┼──────────┤ ││
│ │ T Fin │ 🟡 │ 🔴 │ 🔴 │ ││
│ │ (Jour │ Seulement │ Prochain │ Prochain │ ││
│ │ 7-10) │ si urgent │ sprint │ sprint │ ││
│ │ └──────────┴──────────┴──────────┘ ││
│ │ ││
│ │ 🟢 Risque faible - peut généralement accommoder ││
│ │ 🟡 Risque moyen - nécessite négociation prudente ││
│ │ 🔴 Risque élevé - protéger sprint, reporter au suivant ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Gestion Périmètre GitScrum
Documenter Demandes de Changement
UTILISER DISCUSSIONS POUR DEMANDES DE CHANGEMENT:
Avant de perturber sprint:
┌─────────────────────────────────────────────────────────────┐
│ DISCUSSION: Demande Changement Périmètre │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📋 Demande: Ajouter logique réessai paiement │
│ │
│ ## Détails Demande │
│ **Demandé par:** @stakeholder │
│ **Sprint:** 12 (Jour 4 de 10) │
│ **Urgence revendiquée:** Haute │
│ │
│ ## Analyse Impact │
│ **Effort estimé:** 5 story points │
│ **Capacité sprint restante:** 22 pts │
│ **Impact objectif sprint:** Retarderait objectif │
│ │
│ ## Options │
│ 1. ✅ Ajouter au prochain sprint (risque minimal) │
│ 2. ⚠️ Échanger contre PROJ-78 docs API (points égaux) │
│ 3. 🔴 Ajouter sans retirer (risque burndown) │
│ │
│ ## Décision │
│ [À discuter en sync équipe] │
│ │
└─────────────────────────────────────────────────────────────┘
Suivi Périmètre Sprint
SUIVRE PÉRIMÈTRE ORIGINAL vs ACTUEL:
┌─────────────────────────────────────────────────────────────┐
│ VISIBILITÉ PÉRIMÈTRE SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Utiliser labels pour suivre changements périmètre: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STRATÉGIE LABELS ││
│ │ ││
│ │ scope:original Tâches engagées à la planification ││
│ │ scope:added Ajouté après début sprint ││
│ │ scope:removed Retiré du sprint (raison) ││
│ │ scope:emergency Ajouté pour réponse urgence ││
│ │ scope:expanded Tâche originale a grandi ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Vue filtrée tableau: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SPRINT 12 - Statut Périmètre ││
│ │ ││
│ │ Engagé: 42 pts (10 items) ││
│ │ ├── scope:original 37 pts (8 items) ││
│ │ ├── scope:added 5 pts (2 items) ││
│ │ └── scope:removed -5 pts (1 item → backlog) ││
│ │ ││
│ │ Changement net: 0 pts (échange équilibré) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Protéger Concentration Équipe
Stratégie Buffer
PLANIFIER POUR LE CHANGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUIRE FLEXIBILITÉ DANS LES SPRINTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BUFFER CAPACITÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Si vélocité équipe est 40 pts, ne pas engager 40 pts ││
│ │ ││
│ │ Capacité équipe: 40 pts (vélocité historique) ││
│ │ Travail objectif: 32 pts (80%) ││
│ │ Buffer: 8 pts (20%) ││
│ │ ││
│ │ Usages buffer: ││
│ │ • Changements périmètre inattendus ││
│ │ • Tâches prenant plus que estimé ││
│ │ • Corrections bugs et problèmes support ││
│ │ • Si non utilisé, tirer prochains items backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJECTIFS STRETCH: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Identifier items faible risque à tirer si capacité: ││
│ │ ││
│ │ Engagement core: 32 pts ││
│ │ Stretch goal 1: 5 pts (documentation) ││
│ │ Stretch goal 2: 3 pts (dette technique) ││
│ │ ││
│ │ Stretch goals sont premiers sacrifiés si ││
│ │ changements périmètre arrivent en milieu sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Patterns Communication
Mises à Jour Parties Prenantes
COMMUNIQUER CHANGEMENTS PÉRIMÈTRE:
┌─────────────────────────────────────────────────────────────┐
│ TRANSPARENCE SUR LES CHANGEMENTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ Lors acceptation changement dans sprint: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Nous avons ajouté logique réessai paiement au Sprint ││
│ │ 12. Pour accommoder cela, documentation API passe au ││
│ │ Sprint 13. Objectif sprint reste atteignable." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Lors déclin changement (reporter au prochain sprint): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Logique réessai paiement est priorisée comme premier ││
│ │ item pour Sprint 13, commençant le 20 janvier. ││
│ │ ││
│ │ L'ajouter au Sprint 12 risquerait notre engagement ││
│ │ envers le jalon beta launch du 15 février." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Mesurer Stabilité Périmètre
Métriques Changement Périmètre
SUIVRE PATTERNS CHANGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ MÉTRIQUES POUR RÉTROSPECTIVES │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MÉTRIQUE │ CIBLE │ ACTUEL │ STATUT ││
│ │────────────────────────┼───────────┼────────┼──────────││
│ │ Stabilité périmètre │ 85%+ │ 88% │ 🟢 ││
│ │ (pts complétés / pts │ │ │ ││
│ │ originellement engag) │ │ │ ││
│ │ │ │ │ ││
│ │ Fréquence changements │ <3/sprint │ 2 │ 🟢 ││
│ │ (changements pér/sprt) │ │ │ ││
│ │ │ │ │ ││
│ │ Ajouts urgence │ <1/sprint │ 1 │ 🟡 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Questions rétrospective: │
│ • Changements périmètre étaient-ils vraiment urgents? │
│ • Qu'est-ce qui a causé changements? (Analyse pattern) │
│ • Avions-nous buffer adéquat pour changements? │
│ • Comment changements ont affecté moral et focus équipe? │
│ │
└─────────────────────────────────────────────────────────────┘