Scrum est le framework agile le plus répandu. Il découpe un projet en cycles courts, les sprints, menés par une équipe qui s’organise elle-même. Cette fiche reprend tout ce qu’il faut retenir, du vocabulaire aux pièges classiques.
d’où vient le mot « scrum »
Le mot vient du rugby : la mêlée, où les joueurs s’imbriquent et poussent ensemble pour récupérer le ballon. Nonaka et Takeuchi reprennent l’image dans les années 1980, en observant des équipes chez Fuji-Xerox, Canon et HP. En 1995, Schwaber et Sutherland l’appliquent au logiciel : une équipe soudée, une collaboration intense, une stratégie coordonnée.
des équipes auto-gérées
Scrum fonctionne par sprints (d’une semaine à deux mois) où l’équipe travaille de façon autonome pour produire une version qui fonctionne. Tout repose sur trois « auto- ».
| Principe | Signification |
|---|---|
| Autosuffisance | toutes les compétences et ressources sont en interne, aucune dépendance externe. |
| Auto-gestion | aucune supervision pendant le sprint. Pas de chef de projet, hiérarchie plate, décisions démocratiques. |
| Auto-inspection | la condition de l’auto-gestion : transparence et visibilité du flux. |
Contre-intuition : bien appliqué, Scrum donne plus de contrôle sur le travail et la qualité que le modèle classique, parce qu’il ne dépend plus d’une seule personne externe. Limiter la direction extérieure évite la perte de focus et les surcoûts de changement de contexte.
sprints, MVP et incréments
Le sprint découpe le projet en cycles itératifs. On priorise les fonctionnalités (utilité, criticité, potentiel commercial) pour traiter le cœur du produit au plus tôt et valider les besoins réels.
| Notion | Définition |
|---|---|
| Itératif | repasser sur l’existant pour le corriger et l’améliorer. |
| Incrémental | ajouter de nouvelles fonctionnalités par-dessus. |
| MVP | une version basique mais fonctionnelle et commercialement viable : sa valeur suffit à ce que le client paie. |
Chaque sprint se termine sur un incrément fonctionnel, évaluable par l’équipe et le client. L’exemple classique : un MVP de réservation d’hôtels permet de chercher et trouver un hôtel, sans photos ni paiement. Ces deux fonctions sont des incréments ajoutés après validation.
product-market fit et gestion du risque
Le product-market fit, c’est l’adéquation entre le produit et les besoins d’un client qui paie. Sans demande réelle satisfaite, le produit échoue. Scrum maximise cette adéquation par des sprints courts et une validation constante.
| Modèle | Profil de risque |
|---|---|
| Waterfall | toutes les phases convergent à la fin, sans retour intermédiaire. Si le produit rate le besoin, tout est perdu. |
| Scrum | validation à chaque sprint : on teste le fonctionnement technique et l’adéquation au besoin. |
Image de la bombe : le risque grandit en même temps que le produit. Waterfall ne le désamorce qu’à la livraison finale, Scrum le désamorce un peu à chaque sprint, pendant que la valeur livrée grossit.
les rôles
Le Scrum Guide (Schwaber et Sutherland) officialise rôles, artefacts, événements et vocabulaire. Il évolue et se met à jour régulièrement.
| Rôle | Image | Mission |
|---|---|---|
| Scrum Master | chef d’orchestre | facilite, lève les obstacles, garantit Scrum. Aucune autorité hiérarchique. |
| Product Owner | traducteur | représente le business et les utilisateurs, priorise le product backlog. |
| Development Team | artisans | auto-organisée et pluridisciplinaire, livre des incréments de qualité. |
| Stakeholders | toute personne qui a un intérêt dans le projet : feedback et priorisation. |
artefacts et user stories
| Artefact | Définition | Responsable |
|---|---|---|
| Product Backlog | liste ordonnée de tout le nécessaire, seule source d’exigences. | Product Owner |
| Sprint Backlog | items sélectionnés plus le plan pour atteindre le but du sprint. | Dev Team |
| Incrément | somme des items « terminés » du sprint et des précédents, prêt à l’usage. | Dev Team |
Le besoin s’exprime en user story, toujours sur le même squelette : en tant que (rôle), je veux (fonctionnalité) afin de (bénéfice). Une story complète tient en cinq éléments : description, valeur (1 à 10), estimation (en story points), dépendances, et la Definition of Done convenue entre le client et l’équipe.
les cinq événements
| Événement | Quand | Durée | But |
|---|---|---|---|
| Sprint | 2 sem. à 1 mois | le cœur de Scrum : atteindre les objectifs fixés. | |
| Sprint Planning | début | définir le but et sélectionner les items du backlog. | |
| Daily Scrum | chaque jour | ≤ 15 min | fait hier, prévu aujourd’hui, obstacles. |
| Sprint Review | fin | avec les stakeholders : revue du produit, prochaines étapes. | |
| Sprint Retrospective | fin | auto-évaluation de l’équipe, pistes d’amélioration. |
Piège d’examen : la Review porte sur le produit (avec les stakeholders), la Retrospective sur le process et l’équipe (en interne). Ne pas les confondre.
estimer : le planning poker
L’équipe évalue l’effort des user stories par consensus. Le planning poker utilise des cartes inspirées de Fibonacci (1, 2, 3, 5, 8, 13, 21…) : petits nombres pour le simple et rapide, grands pour la complexité. Déroulé : présentation de la story, discussion, vote simultané, puis revote jusqu’au consensus.
Quelques règles qui protègent le sprint :
- Le Product Owner priorise le backlog en continu (valeur, criticité, stratégie).
- Pendant le sprint, la Dev Team travaille sans interférence : aucune nouvelle tâche imposée.
- Le Scrum Master fait barrage aux stakeholders externes.
- Seul le Product Owner peut décider d’arrêter un sprint, et uniquement en cas grave.
Fiche de révision tirée de la certification « Project Management & Agile Fundamentals », Santander Open Academy. Schémas issus du cours.