Scrum Framework : Sprints, Rôles et Cérémonies
Scrum est le framework Agile le plus populaire au monde, utilisé par 70% des équipes qui adoptent les méthodologies agiles. Créé par Ken Schwaber et Jeff Sutherland au début des années 90, Scrum fournit une structure légère pour gérer des projets complexes de manière itérative et incrémentale.
Ce que vous apprendrez
- Les 3 rôles de Scrum : Product Owner, Scrum Master, Development Team
- Les 5 cérémonies (événements) de Scrum en détail
- Les 3 artefacts : Product Backlog, Sprint Backlog, Incrément
- Le cycle Sprint complet avec chronologie
- Definition of Done et Critères d’Acceptation
- Anti-patterns courants et comment les éviter
- Scrum à l’échelle : SAFe, LeSS, Nexus
Qu’est-ce que Scrum ?
Scrum est un framework empirique basé sur trois piliers :
Les 3 Piliers de Scrum
- Transparence (Transparency) : Tous les aspects du processus sont visibles pour tous
- Inspection (Inspection) : Vérification fréquente de la progression vers les objectifs
- Adaptation (Adaptation) : Ajustements du processus basés sur les résultats
SCRUM FRAMEWORK
├―― 3 RÔLES
│ ├―― Product Owner
│ ├―― Scrum Master
│ └―― Development Team
├―― 5 ÉVÉNEMENTS (Cérémonies)
│ ├―― Sprint
│ ├―― Sprint Planning
│ ├―― Daily Scrum
│ ├―― Sprint Review
│ └―― Sprint Retrospective
└―― 3 ARTEFACTS
├―― Product Backlog
├―― Sprint Backlog
└―― IncrémentLes 3 Rôles de Scrum
1. Product Owner (PO)
Le Product Owner est le « propriétaire du produit », responsable de maximiser la valeur du travail de l’équipe.
Responsabilités du Product Owner
- Vision du produit : Définir et communiquer la vision produit
- Gestion du Product Backlog : Créer, ordonner et maintenir le backlog
- Priorisation : Décider de ce qui est le plus important (piloté par le ROI)
- Acceptation du travail : Approuver/refuser les user stories complétées
- Engagement parties prenantes : Interface entre l’équipe et le client/métier
- Décideur : A le dernier mot sur « quoi » construire (pas « comment »)
PO Efficace
- Disponible pour l’équipe quotidiennement
- Décisions rapides
- Vision claire du produit
- Connaît le domaine métier
- Autonome (a l’autorité)
- Collaboratif avec l’équipe
PO Inefficace
- Absent/indisponible
- Décisions lentes ou indécises
- PO « par comité »
- Ne connaît pas le métier
- Simple proxy, pas d’autorité
- Micro-management de l’équipe
2. Scrum Master
Le Scrum Master est le servant leader qui aide l’équipe et l’organisation à adopter Scrum de manière efficace.
Responsabilités du Scrum Master
Service au Development Team :
- Coaching sur l’auto-organisation et la cross-fonctionnalité
- Suppression des obstacles (blockers)
- Facilitation des événements Scrum
- Protection de l’équipe contre les distractions externes
Service au Product Owner :
- Aide à gérer efficacement le Product Backlog
- Facilitation de la collaboration avec l’équipe
- Coaching sur les pratiques Agile
Service à l’Organisation :
- Guider l’adoption de Scrum dans l’organisation
- Augmenter la productivité de l’équipe
- Travailler avec les autres Scrum Masters
Le Scrum Master N’est PAS :
- Un Chef de Projet (Scrum n’a pas de PM !)
- Un Team Lead ou Manager
- Un secrétaire de l’équipe
- Responsable de la livraison
- Un leader technique
Le Scrum Master est un facilitateur et coach, pas un manager avec autorité sur l’équipe.
3. Development Team
Le Development Team est un groupe de professionnels qui travaillent ensemble pour livrer un incrément « Done » du produit à la fin de chaque Sprint.
Caractéristiques du Development Team
- Auto-organisé : Décide de manière autonome comment réaliser le travail
- Cross-functional : Possède toutes les compétences nécessaires (dev, test, design, etc.)
- Pas de sous-équipe : Pas d’équipes « frontend » ou « backend » séparées
- Pas de titres : Tous sont « Developer » (pas de hiérarchie interne)
- Responsable en tant qu’équipe : Succès et échecs sont collectifs
- Taille optimale : 3 à 9 personnes (idéal : 5-7)
Les 5 Cérémonies de Scrum
1. Sprint (Conteneur Time-Boxé)
Le Sprint est le cœur de Scrum : un cycle time-boxé de 1 à 4 semaines (le plus courant : 2 semaines) pendant lequel est créé un incrément « Done » du produit.
Règles du Sprint
- Durée fixe : Toujours la même durée pour tous les sprints
- Sprint Goal : Objectif clair et partagé
- Pas de changements : Le périmètre ne change pas pendant le sprint (focus)
- Qualité : La Definition of Done n’est pas compromise
- Annulation : Seul le PO peut annuler un sprint (rare !)
2. Sprint Planning
Time-box : Maximum 8 heures pour un sprint d’un mois (proportionnel pour des sprints plus courts).
Participants : Toute l’équipe Scrum (PO, SM, Dev Team).
PARTIE 1 : QUOI ? (Que ferons-nous ?)
Durée : ~50% du temps (ex : 2 heures pour un sprint de 2 semaines)
1. Le Product Owner présente les éléments prioritaires du backlog
2. L’équipe pose des questions pour comprendre les exigences
3. L’équipe sélectionne les éléments pour le sprint (pull, pas push !)
4. Le Sprint Goal est défini
Résultat : Sprint Backlog (liste des user stories sélectionnées)
---
PARTIE 2 : COMMENT ? (Comment le réaliserons-nous ?)
Durée : ~50% du temps
1. L’équipe décompose chaque user story en tâches techniques
2. Estimation de l’effort en heures pour chaque tâche
3. Identification des dépendances et risques
4. Validation de la capacité (velocity historique)
5. Engagement de l’équipe
Résultat : Sprint Backlog détaillé avec tâches3. Daily Scrum (Standup)
Time-box : 15 minutes (fixe !).
Participants : Development Team (obligatoire), SM facilite, PO optionnel.
Quand : Même heure, même lieu, chaque jour.
Les 3 Questions Classiques
Chaque membre de l’équipe répond :
- Qu’ai-je fait hier pour aider l’équipe vers le Sprint Goal ?
- Que vais-je faire aujourd’hui pour aider l’équipe vers le Sprint Goal ?
- Ai-je des obstacles qui me bloquent ou bloquent l’équipe ?
Anti-Patterns du Daily Scrum
- Rapport de statut au manager : Ce n’est pas un reporting hiérarchique !
- Résolution de problèmes : Le daily est pour la synchronisation, pas pour résoudre des problèmes (réunion après)
- Durée > 15 min : Le time-box est sacré, discussions hors du daily
- Seul le Scrum Master parle : Ce doit être une conversation d’équipe
4. Sprint Review
Time-box : Maximum 4 heures pour un sprint d’un mois (ex : 2 heures pour un sprint de 2 semaines).
Participants : Équipe Scrum + Parties prenantes + Client.
Agenda Sprint Review
- Ouverture (5 min) : Le PO rappelle le Sprint Goal et ce qui était planifié
- Démo (60%) : L’équipe montre le logiciel fonctionnel (démo live, pas de slides !)
- Uniquement les fonctionnalités « Done » selon la DoD
- Environnement staging/production-like
- Interactif : les parties prenantes essaient le produit
- Feedback (30%) : Les parties prenantes fournissent des retours
- Qu’est-ce qui fonctionne bien ?
- Que manque-t-il ou doit être modifié ?
- Nouvelles idées émergées
- Mise à jour du Product Backlog (10%) : Le PO met à jour le backlog avec les retours
5. Sprint Retrospective
Time-box : Maximum 3 heures pour un sprint d’un mois (ex : 1,5 heure pour un sprint de 2 semaines).
Participants : Uniquement l’équipe Scrum (PO, SM, Dev Team). Pas de parties prenantes externes !
Quand : Après la Sprint Review, avant le prochain Planning.
Objectif de la Rétrospective
Inspection et adaptation du processus de travail (pas du produit). Focus sur :
- Qu’est-ce qui a bien fonctionné ? (Continuer)
- Qu’est-ce qui a mal fonctionné ? (Arrêter)
- Que pouvons-nous améliorer ? (Commencer)
TECHNIQUE 1 : Start-Stop-Continue
┌―――――――――――――┐―――――――――――――┐―――――――――――――┌
│ COMMENCER │ ARRÊTER │ CONTINUER │
├―――――――――――――⊞―――――――――――――⊞―――――――――――――├
│ Pair │ Heures │ Revues de │
│ programming │ suppl. │ code │
│ │ │ │
│ Tests │ Sauter les │ Daily │
│ automatisés │ rétros │ standups │
└―――――――――――――┘―――――――――――――┘―――――――――――――└
TECHNIQUE 2 : Radar du Bonheur
L’équipe note (1-5) différentes catégories :
- Collaboration : Excellent !
- Qualité technique : À améliorer
- Équilibre vie pro/perso : ALERTE ROUGE !
- Clarté du Sprint Goal : Bien
TECHNIQUE 3 : Rétrospective Voilier
Objectif (île) : Où voulons-nous aller ?
Vents : Qu’est-ce qui nous pousse en avant ?
Ancres : Qu’est-ce qui nous retient ?
Rochers : Quels risques éviter ?
RÉSULTAT : 1-3 ACTIONS concrètes
Action : «Introduire TDD dès le prochain sprint»
Responsable : Toute l’équipe
Échéance : Sprint 15
Succès : 50% du nouveau code a des tests d’abordRègles de la Rétrospective
- Espace sûr : Ce qui se dit en rétro reste en rétro
- Pas de blâme : Focus sur le processus, pas sur les personnes
- Honnêteté : Exprimez-vous ! C’est le moment d’améliorer
- Orienté action : Pas seulement des plaintes, aussi des solutions
- Suivi : Revue des actions du sprint précédent
Les 3 Artefacts de Scrum
1. Product Backlog
Liste ordonnée et dynamique de tout le travail nécessaire pour le produit. Propriété du Product Owner.
Caractéristiques du Product Backlog
- Ordonné (pas priorisé) : Séquence unique, le haut = prochain sprint
- Émergent : Évolue continuellement, jamais « complet »
- Détaillé adéquatement : Éléments du haut détaillés, du bas vagues
- Estimé : Story points ou autre métrique relative
- Transparent : Visible par tous
2. Sprint Backlog
Sous-ensemble du Product Backlog sélectionné pour le Sprint en cours + plan pour le livrer. Propriété du Development Team.
3. Incrément
La somme de tous les éléments du Product Backlog complétés pendant un Sprint + la valeur des incréments de tous les Sprints précédents. Doit être « Done » selon la Definition of Done.
Definition of Done (DoD)
Critères partagés et clairs pour déterminer quand un travail est considéré complet. Non négociable !
Anti-Patterns Scrum Courants
Erreurs à Éviter
1. Scrum Mais (Scrum But)
Symptôme : « On fait du Scrum mais... [exception] »
- « Scrum mais sans Daily Scrum » → Ce n’est pas Scrum
- « Scrum mais sans Rétrospective » → Vous ne vous améliorerez jamais
- « Scrum mais le PO n’est pas disponible » → Équipe continuellement bloquée
2. Sprint comme Mini-Waterfall
Problème : Toutes les phases en séquence dans le sprint
MAUVAIS : Sprint = Conception → Dev → Test → Deploy (waterfall !)
BON : Sprint = Itérer sur les fonctionnalités, chaque fonctionnalité complètement Done3. Sprint Goal Absent ou Vague
Problème : Le sprint est juste une « liste de tâches » sans objectif cohérent
- MAUVAIS : « Compléter les stories 45, 46, 47, 48 »
- BON : « Permettre aux utilisateurs de finaliser un achat sans inscription »
4. Velocity comme Engagement Fixe
Problème : Le management utilise la velocity pour mettre la pression sur l’équipe
- La velocity est une métrique de planning, pas un objectif à atteindre !
- Une équipe sous pression gonfle ses estimations → la velocity perd tout sens
Scrum à l’Échelle
Lorsque l’organisation a de nombreuses équipes Scrum, des frameworks de coordination sont nécessaires. Les 3 principaux :
SAFe (Scaled Agile Framework)
- Framework le plus populaire pour l’entreprise
- 4 niveaux : Team, Program, Large Solution, Portfolio
- Program Increment (PI) de 8-12 semaines
- Agile Release Train (ART) : 50-125 personnes
- Avantages : Structuré, documenté, adapté aux grandes organisations
- Inconvénients : Lourd, moins agile que le Scrum pur
LeSS (Large-Scale Scrum)
- Scrum étendu à plusieurs équipes (2-8 équipes)
- 1 Product Owner pour toutes les équipes
- 1 Product Backlog partagé
- Sprints synchronisés
- Rétrospective globale cross-équipe
- Avantages : Maintient la simplicité de Scrum
- Inconvénients : Nécessite une haute maturité Agile
Nexus
- Framework Scrum.org pour 3-9 équipes
- Nexus Integration Team coordonne
- Nexus Sprint Planning, Review, Retrospective
- Focus sur l’intégration continue
- Avantages : Officiel de Scrum.org
- Inconvénients : Limité à ~100 personnes
Conclusions
Scrum fournit une structure simple mais puissante pour le développement Agile. La clé du succès est l’adoption rigoureuse du framework (pas de Scrum But !) combinée à une inspection et adaptation continues.
Points Clés
- Scrum a 3 rôles, 5 événements, 3 artefacts - tous essentiels
- Le Product Owner maximise la valeur, le Scrum Master facilite, le Dev Team livre
- Le Sprint est un cycle time-boxé (1-4 semaines) avec un objectif clair
- La Definition of Done est un critère non négociable pour la qualité
- La Rétrospective est le moteur de l’amélioration continue
- Transparence, Inspection, Adaptation sont les 3 piliers
- Scrum à l’échelle nécessite des frameworks additionnels (SAFe, LeSS, Nexus)
Article Suivant
Dans le prochain article, nous explorerons la Méthode Kanban : le système à flux continu avec limites WIP, tableau Kanban, métriques de flux (Lead Time, Cycle Time) et comparaison avec Scrum.