Révision QCM — Agile et Scrum
Les 8 thèmes du QCM, du plus au moins représenté : rôles et responsabilités, sprint et rituels, user stories et estimation, PDCA, Manifeste agile, management visuel, équipe, artefacts.
Cette fiche couvre les 8 thèmes du QCM, dans l'ordre de leur poids : les trois premiers pèsent à eux seuls près de la moitié des questions. Les thèmes 1, 2, 7 et 8 suivent le cours — le Guide Scrum 2020. Les thèmes 3 à 6 (user stories, PDCA, Manifeste agile, management visuel) n'ont pas de PDF de cours sur ce site : ils sont résumés ici d'après les références classiques, puisque le QCM les annonce. Les encadrés « piège » signalent les formulations qui se ressemblent et se confondent le jour du contrôle.
1. Scrum — rôles et responsabilités
Les trois responsabilités d'une Scrum Team, et ce dont chacune est redevable :
| Responsabilité | Ce dont elle répond |
|---|---|
| Product Owner | Maximiser la valeur du produit. Il ordonne le Product Backlog et le rend transparent et compris. C'est une personne, pas un comité. |
| Scrum Master | La mise en place de Scrum telle que définie par le Guide, et l'efficacité de l'équipe. Leader au service : il lève les obstacles, veille à ce que les événements aient lieu et tiennent dans leur créneau. |
| Developers | Créer le Sprint Backlog, inculquer la qualité via la Definition of Done, adapter leur plan chaque jour, se tenir mutuellement responsables. |
Les cinq questions qui reviennent le plus :
| Question | Réponse |
|---|---|
| Qui estime le travail ? | Les Developers. Ni le Product Owner ni le Scrum Master ne votent : ce sont eux qui font le travail, donc eux qui l'estiment. |
| Qui priorise le Product Backlog ? | Le Product Owner, et lui seul. Pour changer une priorité, il faut le convaincre. |
| Qui est garant du cadre de travail ? | Le Scrum Master. Il veille au respect du Guide — ce n'est pas un chef de projet. |
| Qui est responsable de la qualité ? | Les Developers, via la Definition of Done. La qualité est l'affaire de toute l'équipe, et les objectifs de qualité ne sont jamais revus à la baisse. |
| Qui peut annuler un Sprint ? | Le Product Owner, et uniquement si l'Objectif de Sprint devient obsolète. |
Piège — le Scrum Master
C'est un leader au service de l'équipe et de l'organisation. Il ne distribue pas les tâches, ne fixe pas les priorités et ne rend pas de comptes sur l'avancement : c'est un chef de projet qui ferait tout cela, et ce n'est pas son rôle.
2. Scrum — Sprint et rituels
| Événement | Objet | Durée max (Sprint d'un mois) |
|---|---|---|
| Sprint | Le conteneur de tous les autres événements | 1 mois ou moins |
| Sprint Planning | Définir pourquoi, quoi et comment | 8 heures |
| Daily Scrum | Inspecter la progression vers l'Objectif de Sprint | 15 minutes |
| Sprint Review | Inspecter le résultat et décider des adaptations | 4 heures |
| Sprint Retrospective | Améliorer la qualité et l'efficacité de l'équipe | 3 heures |
Le détail qui fait la différence :
- Combien d'événements ? Le Guide écrit noir sur blanc : « Scrum combine quatre événements formels […] dans un événement conteneur, le Sprint ». Donc 4 + 1 : quatre événements à l'intérieur du Sprint, et le Sprint qui les contient. Si la question demande « combien d'événements ? », précise la distinction : répondre « 5 » sans nuance ou « 4 » sans nuance rate la moitié de la réponse. Le tableau ci-dessus compte bien cinq lignes, mais la cinquième est le conteneur.
- Durée d'un Sprint — un mois ou moins, et la même pour tous les Sprints d'une équipe. Un nouveau Sprint commence immédiatement après le précédent : il n'y a pas de pause entre deux Sprints. Plus l'horizon est lointain, plus l'Objectif de Sprint risque d'être obsolète et plus le risque augmente.
- Daily meeting — 15 minutes, pour les Developers. Ce n'est pas un compte rendu d'avancement à la hiérarchie : sa structure est libre, tant qu'il porte sur la progression vers l'Objectif de Sprint.
- Rétrospective — elle clôt le Sprint. C'est le moment d'amélioration continue de l'équipe : elle porte sur les personnes, les interactions, les processus et les outils.
- Fin de sprint — elle intervient à la fin de la timebox. Un Objectif de Sprint non atteint n'est pas un échec : on inspecte et on s'adapte au Sprint suivant. Ce qui compte, c'est que l'Increment livré soit utilisable.
- Réduction du Sprint Backlog — le Sprint Backlog est un plan par et pour les Developers : ils le mettent à jour chaque jour. Ils peuvent donc en retirer des éléments qu'ils ne feront pas, à deux conditions : ne pas remettre en cause l'Objectif de Sprint, et ne jamais revoir la qualité à la baisse. Le travail restant décroît au fil du Sprint.
3. User stories et estimation
Composer une user story
Une US se lit en trois parties — c'est la réponse à « de quoi une user story est-elle composée ? » :
| Partie | Question à laquelle elle répond |
|---|---|
| Qui | quel rôle, quelle personne est concernée |
| Quoi | quelle fonctionnalité est attendue |
| Pourquoi | quel bénéfice, quelle valeur en est tiré |
La forme canonique : « En tant que rôle, je veux fonctionnalité, afin de bénéfice. » On y ajoute des critères d'acceptation, qui disent à quelle condition la story est terminée.
« Composition d'une US » — deux lectures possibles
La question peut viser deux choses différentes : savoir donner les deux.
- la formule — rôle, fonctionnalité, bénéfice : « En tant que… je veux… afin de… » ;
- les 3 C de Ron Jeffries — Card (la carte : un simple rappel écrit, pas une spécification), Conversation (la discussion avec le Product Owner), Confirmation (les exemples concrets et testables qui prouvent que c'est fait — autrement dit les critères d'acceptation).
Le Card n'est pas un document de spécification : s'il n'y a pas la place d'écrire la story sur la carte, c'est qu'il faut une story plus petite. C'est la même idée que « une US tient dans un Sprint » — la carte est un pense-bête, pas un cahier des charges.
Durée et nombre
Une US doit tenir dans un seul Sprint : si elle ne tient pas, on la découpe. C'est un rappel de ce qu'il faut faire, pas une spécification complète — elle se discute avec le Product Owner.
Il n'existe aucun nombre d'US par projet. Le nombre dépend entièrement du découpage, et le Product Backlog est émergent : il grossit, se réordonne et s'affine en permanence.
Le poker planning
Objectif : estimer collectivement, en relatif, et surtout faire apparaître les désaccords. Les écarts entre les votes ne sont pas un problème, c'est le but : ils révèlent que deux personnes n'ont pas la même idée de la complexité. On discute, puis on revote jusqu'à convergence. La suite utilisée est Fibonacci (1, 2, 3, 5, 8, 13, 21), souvent complétée par une carte ? (« je ne sais pas ») et une carte « pause ».
Le vote est simultané, et ce n'est pas un détail : révéler les cartes en même temps empêche le premier chiffre annoncé de tirer l'estimation à lui — c'est l'ancrage. Sans le vote simultané, l'équipe se rallie au premier avis exprimé au lieu de confronter les points de vue.
Points d'effort ou jours-homme ?
| Points d'effort | Jours-homme | |
|---|---|---|
| Nature | Relatif, sans unité | Absolu, en jours |
| Ce qu'on compare | Des US entre elles, dans une même équipe | Des personnes, des projets, des coûts |
| Dépend de l'équipe ? | Oui — les points sont propres à l'équipe | Non : un jour reste un jour |
| À quoi ça sert | Planifier, mesurer la vélocité | Chiffrer un budget, un délai |
Convertir des points en jours-homme défait ce qui fait l'intérêt des points : ils sont relatifs et propres à une équipe, donc la conversion n'a pas de sens — la vélocité d'une équipe ne se compare pas à celle d'une autre, et ne se transforme pas en durée. Retenir la raison (« relatif, propre à l'équipe ») plutôt que le slogan : c'est elle qui est demandée.
4. PDCA — l'amélioration continue
Plan – Do – Check – Act : la roue de Deming. C'est une méthode d'amélioration continue et de résolution de problèmes — on ne l'applique pas une fois, on la fait tourner.
| Étape | Ce qu'on y fait |
|---|---|
| Plan — planifier | 1. Identifier le problème ou l'opportunité. 2. Fixer les objectifs (le résultat attendu). 3. Élaborer le plan d'action. |
| Do — faire | Mettre en œuvre le plan à petite échelle, sur un périmètre restreint, et collecter les données. |
| Check — vérifier | Comparer les résultats obtenus aux objectifs et identifier les écarts. |
| Act — agir | Standardiser si c'est concluant, corriger sinon — puis mettre à jour le plan et relancer un tour. |
Sur la durée du Do : elle est courte, volontairement. Le Do est une expérimentation menée sur un périmètre limité, juste assez longtemps pour obtenir des résultats exploitables — pas un déploiement général. C'est ce qui permet de boucler vite et de corriger avant d'industrialiser.
PDCA et Scrum
La Sprint Retrospective est le moment PDCA de Scrum : on inspecte ce qui vient de se passer (Check), on décide d'un changement (Act) qu'on appliquera au Sprint suivant (Plan, puis Do).
5. Manifeste agile et valeurs
La définition de l'agilité — le piège
L'agilité n'est pas « aller vite », ni « travailler sans plan », ni « ne pas documenter ». C'est la capacité à s'adapter au changement et à livrer de la valeur par petites itérations, en s'appuyant sur le retour du terrain. Une équipe agile peut avancer lentement : ce qui la définit, c'est sa capacité de réaction, pas sa vitesse.
Les 4 valeurs du Manifeste agile (2001)
Elles s'énoncent toujours en « X plutôt que Y » :
| On donne plus de valeur à… | …qu'à |
|---|---|
| Les individus et leurs interactions | les processus et les outils |
| Des logiciels opérationnels | une documentation exhaustive |
| La collaboration avec le client | la négociation contractuelle |
| L'adaptation au changement | le suivi d'un plan |
Piège — la valeur qui n'en fait pas partie
Attention à ne pas confondre deux listes :
- les 4 valeurs du Manifeste agile : individus et interactions, logiciels opérationnels, collaboration avec le client, adaptation au changement ;
- les 5 valeurs de Scrum : engagement, focus, ouverture, respect, courage.
« Le courage » ou « le respect » ne sont donc pas des valeurs du Manifeste. Et les 12 principes (satisfaire le client, livrer souvent, s'organiser soi-même…) sont des principes, pas des valeurs.
La place de la documentation
Le second terme d'une valeur n'est jamais sans valeur — il en a simplement moins. Le Manifeste le dit dans sa phrase-charnière : il y a de la valeur dans les éléments de droite, mais on valorise davantage ceux de gauche. Dire que « le Manifeste interdit la documentation » est donc faux : elle reste utile, elle passe simplement après un logiciel qui fonctionne. On documente ce qui sert — l'équipe, le client, la maintenance — pas pour cocher une case : l'excès de documentation est du gaspillage au sens Lean.
6. Management visuel et outils
| Outil | Ce qu'il apporte |
|---|---|
| Management visuel | Rendre le travail visible, par l'équipe et par ceux qui l'entourent. Un problème qui se voit se règle ; un problème caché s'accumule. C'est le pilier transparence rendu concret. |
| Rayonnement de l'information | L'information doit rayonner : compréhensible sans explication et visible au-delà de l'équipe (parties prenantes, encadrement, visiteurs). Un tableau que seul son auteur sait lire n'est pas du management visuel. |
| Tableau Kanban | Visualiser le flux en colonnes (À faire / En cours / Fait) et limiter le travail en cours (WIP). La limite de WIP est le cœur de Kanban : elle fait apparaître les goulets d'étranglement et force à finir avant de commencer. |
| Graphique burn-up | Montrer le travail accompli cumulé qui monte vers une ligne d'objectif (le périmètre total). Ce qui reste se lit dans l'écart vertical à cette ligne. |
Piège — burn-up ou burn-down ?
Le burn-down part du total et descend vers zéro : il trace le travail restant. Le burn-up part de zéro et monte vers une ligne d'objectif : il trace le travail accompli. Le burn-up a un avantage décisif : quand le périmètre change, sa ligne d'objectif bouge avec lui et l'écart reste lisible, alors que le burn-down laisse croire à un simple retard.
Autre précision : Kanban n'impose pas d'itérations. Contrairement à Scrum, il se superpose au processus existant et se contente de visualiser et de limiter le flux.
7. Scrum — l'équipe
| Point | Réponse |
|---|---|
| Taille | Une petite équipe : habituellement dix personnes au plus — le Guide 2020 ne fixe aucun minimum. Ses mots exacts : « suffisamment petite pour rester réactive et assez grande pour accomplir un travail significatif durant le Sprint ». Au-delà, se réorganiser en plusieurs Scrum Teams cohérentes, chacune axée sur le même produit — elles partagent alors le même Objectif de Produit, le même Product Backlog et le même Product Owner. |
| Pluridisciplinaire | L'équipe réunit toutes les compétences nécessaires pour livrer un Increment utilisable à chaque Sprint, sans dépendre d'une autre équipe. |
| Autogérée | Elle décide en interne qui fait quoi, quand et comment. |
| Une seule équipe | Pas d'« équipe dans l'équipe », pas de sous-équipe, pas de hiérarchie interne. |
Piège — « 3 à 9 » ou « dix personnes au plus » ?
Le cours — donc le Guide Scrum 2020 — retient une petite équipe : « suffisamment petite pour rester réactive », habituellement dix personnes au plus, sans minimum. Le chiffre « 3 à 9 » vient du Guide 2017 : il circule encore beaucoup et figure dans l'annonce des thèmes du QCM.
Si la question porte sur la taille d'une Scrum Team, la réponse du cours est « dix personnes au plus ». Reconnais « 3 à 9 » comme la formulation de l'ancien Guide.
8. Scrum — backlog et artefacts
Composition du Product Backlog
- une liste ordonnée et émergente de tout ce qui est nécessaire pour améliorer le produit — fonctionnalités, améliorations, corrections ;
- l'unique source du travail entrepris par la Scrum Team ;
- jamais terminé : il évolue en permanence. L'affiner consiste à décomposer ses éléments en éléments plus fins et plus précis ;
- son engagement est l'Objectif de Produit, un état futur visé à long terme.
Composition du Sprint Backlog
Trois ingrédients, dans cet ordre :
| Ingrédient | Contenu |
|---|---|
| le pourquoi | l'Objectif de Sprint |
| le quoi | les éléments du Product Backlog sélectionnés pour ce Sprint |
| le comment | le plan d'action concret des Developers |
C'est un plan par et pour les Developers, mis à jour chaque jour. Son engagement est l'Objectif de Sprint.
Les artefacts et leurs engagements
| Artefact | Engagement | Contenu |
|---|---|---|
| Product Backlog | Objectif de Produit | liste ordonnée et émergente de tout ce qui améliore le produit |
| Sprint Backlog | Objectif de Sprint | pourquoi + quoi + comment |
| Increment | Definition of Done | une étape concrète et utilisable vers l'Objectif de Produit |
Un travail qui ne remplit pas la Definition of Done n'est pas un Increment : il retourne au Product Backlog.
Les chiffres à retenir
À réciter la veille
- Habituellement dix personnes au plus dans une Scrum Team, sans minimum (« 3 à 9 » = Guide 2017).
- 1 mois ou moins par Sprint, et le suivant démarre immédiatement.
- 15 min de Daily · 8 h de Planning · 4 h de Review · 3 h de Retro (pour un Sprint d'un mois).
- 3 responsabilités (PO, SM, Developers) · 3 artefacts · 3 piliers (transparence, inspection, adaptation) · 5 valeurs Scrum.
- 4 événements formels dans le Sprint, qui est lui-même l'événement conteneur — soit 5 si l'on compte le Sprint. Le Guide dit « quatre ».
- 4 valeurs du Manifeste agile · 4 étapes du PDCA.
- Suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21.
Les cinq pièges à ne pas lâcher
- Les 5 valeurs de Scrum ne sont pas les 4 valeurs du Manifeste agile.
- Le burn-up monte (accompli), le burn-down descend (restant).
- Les points d'effort ne se convertissent pas en jours-homme.
- Le Scrum Master n'est pas un chef de projet ; le Product Owner n'est pas un comité.
- La documentation n'est pas interdite par le Manifeste : elle est moins prioritaire qu'un logiciel qui fonctionne.
Dernière mise à jour le