Cadre Scrum : rôles, événements et artefacts
Définition
Scrum est le cadre agile le plus utilisé et le plus testé au CAPM. C'est un framework léger basé sur l'empirisme (transparence, inspection, adaptation) qui organise le travail en itérations fixes appelées sprints. Il définit 3 rôles, 5 événements et 3 artefacts.
| Composant |
Éléments |
| Rôles (3) |
Product Owner, Scrum Master, Développeurs |
| Événements (5) |
Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective |
| Artefacts (3) |
Product Backlog, Sprint Backlog, Incrément |
Contexte
Le CAPM couvre Scrum dans le domaine « Cadres agiles/méthodologies ». Les questions portent sur les responsabilités de chaque rôle, le but de chaque événement, et la distinction entre artefacts. L'erreur la plus testée : confondre les responsabilités du Product Owner et du Scrum Master.
Détails techniques
Les 3 rôles Scrum
| Rôle |
Responsabilité principale |
Ce qu'il ne fait PAS |
| Product Owner |
Maximiser la valeur du produit, gérer le Product Backlog, définir les priorités |
Ne dirige pas l'équipe, ne décide pas du « comment » |
| Scrum Master |
Faciliter Scrum, éliminer les obstacles, coacher l'équipe et l'organisation |
Ne gère pas le périmètre, ne prend pas de décisions produit |
| Développeurs |
Créer l'incrément « Done » à chaque sprint, auto-organisation |
Ne définissent pas les priorités business |
Piège d'examen : Le Scrum Master n'est PAS un chef de projet. C'est un servant leader qui facilite. Le Product Owner n'est PAS un business analyst — il est le décideur de la valeur.
Les 5 événements Scrum
| Événement |
Durée (sprint 2 sem.) |
Participants |
But |
| Sprint |
2 semaines (fixe) |
Toute l'équipe |
Conteneur pour tous les autres événements |
| Sprint Planning |
≤ 4 heures |
PO + SM + Dev |
Définir le Sprint Goal + sélectionner les items du backlog |
| Daily Scrum |
≤ 15 minutes |
Développeurs (SM facilite) |
Synchroniser, identifier les blocages |
| Sprint Review |
≤ 2 heures |
Équipe + parties prenantes |
Inspecter l'incrément, recueillir le feedback |
| Sprint Retrospective |
≤ 1.5 heures |
Équipe Scrum (interne) |
Améliorer le processus pour le prochain sprint |
Flux d'un sprint
Product Sprint Daily Sprint Sprint
Backlog → Planning → Scrum → Review → Retrospective
│ (quoi+comment) (x10) (feedback) (amélioration)
│ │ │ │
│ ▼ ▼ │
│ Sprint Backlog Incrément "Done" │
│ │
└──────────── Backlog mis à jour ←─────────────────┘
Les 3 artefacts et leurs engagements
| Artefact |
Contenu |
Engagement associé |
| Product Backlog |
Liste ordonnée de tout ce que le produit pourrait nécessiter |
Product Goal (objectif produit à long terme) |
| Sprint Backlog |
Items sélectionnés + plan pour les réaliser |
Sprint Goal (objectif du sprint) |
| Incrément |
Somme de tous les items « Done » de tous les sprints |
Definition of Done (critères de qualité) |
Comparaison Sprint Review vs Retrospective
| Aspect |
Sprint Review |
Sprint Retrospective |
| Focus |
Le produit (quoi) |
Le processus (comment) |
| Participants |
Équipe + parties prenantes externes |
Équipe Scrum uniquement |
| Résultat |
Feedback, backlog mis à jour |
Améliorations pour le prochain sprint |
| Orientation |
Client et valeur |
Équipe et efficacité |
Valeurs Scrum
| Valeur |
Application |
| Courage |
Aborder les problèmes difficiles |
| Focus |
Se concentrer sur le travail du sprint |
| Engagement |
S'engager sur les objectifs de l'équipe |
| Respect |
Se respecter mutuellement comme professionnels |
| Ouverture |
Être transparent sur le travail et les difficultés |
Exemple concret
Sprint 4 d'un projet d'application mobile bancaire :
- Sprint Planning : Le PO présente les 12 items prioritaires du Product Backlog. L'équipe de 6 développeurs sélectionne 8 items réalisables en 2 semaines. Sprint Goal : « Les utilisateurs peuvent effectuer un virement entre comptes ».
- Daily Scrum (jour 7) : Un dev signale un blocage sur l'API de la banque partenaire → le Scrum Master contacte l'équipe technique partenaire pour débloquer.
- Sprint Review : Démo du virement fonctionnel devant le PO et 3 représentants métier. Feedback : ajouter la confirmation par SMS → ajouté au Product Backlog (pas au sprint en cours).
- Sprint Retrospective : L'équipe décide d'ajouter des tests d'intégration automatisés dès le prochain sprint pour éviter les régressions.
