Scrum Débutant — Rôles et Artifacts

Q: Qu'est-ce que Scrum ?

Bonne réponse : Un framework agile léger pour la gestion de projets complexes, basé sur des cycles itératifs appelés Sprints. Scrum est un framework agile défini dans le Scrum Guide par Ken Schwaber et Jeff Sutherland. Il repose sur des cycles itératifs et incrémentaux (Sprints), des rôles définis, des événements et des artifacts pour livrer de la valeur de manière empirique.

Q: Quels sont les trois piliers empiriques de Scrum ?

Bonne réponse : Transparence, Inspection, Adaptation. Les trois piliers de l'empirisme Scrum sont : Transparence (le processus et le travail doivent être visibles), Inspection (vérifier fréquemment les artifacts et les progrès), Adaptation (ajuster si le processus dévie des limites acceptables).

Q: Qui est responsable du Product Backlog dans Scrum ?

Bonne réponse : Le Product Owner. Le Product Owner est le seul responsable du Product Backlog. Il gère son contenu, sa disponibilité et son ordonnancement (priorisation). Il peut déléguer la rédaction mais reste comptable du résultat.

Q: Quelle est la durée maximale recommandée pour un Sprint selon le Scrum Guide ?

Bonne réponse : Un mois (4 semaines). Le Scrum Guide stipule qu'un Sprint ne doit pas dépasser un mois. S'il est plus long, la définition de ce qui est construit peut changer, la complexité peut augmenter, et le risque peut s'accroître.

Q: Quel est le rôle principal du Scrum Master ?

Bonne réponse : Faciliter Scrum, coacher l'équipe, supprimer les obstacles, et promouvoir l'amélioration continue. Le Scrum Master est un servant-leader qui aide l'équipe Scrum à comprendre et appliquer Scrum. Il facilite les événements, supprime les impediments (obstacles), coache l'équipe vers l'auto-organisation, et protège l'équipe des perturbations externes.

Q: Qu'est-ce que le Sprint Backlog ?

Bonne réponse : L'ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan pour livrer l'incrément. Le Sprint Backlog est composé du Sprint Goal (pourquoi), des Product Backlog Items sélectionnés pour le Sprint (quoi), et d'un plan pour livrer l'incrément (comment). Il est créé par les développeurs pendant le Sprint Planning.

Q: Qu'est-ce que le Daily Scrum (mêlée quotidienne) ?

Bonne réponse : Un événement quotidien de 15 minutes où les développeurs inspectent les progrès vers le Sprint Goal. Le Daily Scrum est un événement limité à 15 minutes, tenu chaque jour ouvré du Sprint, exclusivement par et pour les développeurs. Ils inspectent le progrès vers le Sprint Goal et adaptent le Sprint Backlog si nécessaire.

Q: Quels sont les trois rôles dans une équipe Scrum ?

Bonne réponse : Product Owner, Scrum Master, Développeurs. L'équipe Scrum se compose de trois rôles (appelés "accountabilities" depuis Scrum Guide 2020) : Product Owner (maximise la valeur du produit), Scrum Master (facilite Scrum et l'amélioration continue), Développeurs (créent l'incrément).

Q: Qu'est-ce que la Définition of Done (DoD) ?

Bonne réponse : Une checklist formelle définissant les critères de qualité qu'un incrément doit respecter pour être considéré comme terminé. La Definition of Done (DoD) est un engagement formel pour l'incrément. C'est une liste de critères que chaque Product Backlog Item doit satisfaire pour être considéré comme "Done". Elle assure la transparence sur la qualité.

Q: Quel est le timebox (durée maximale) recommandé pour un Sprint Planning pour un Sprint d'un mois ?

Bonne réponse : 8 heures. Pour un Sprint d'un mois, le Sprint Planning est limité à 8 heures. Pour des Sprints plus courts, la durée est proportionnellement réduite (ex: 4 heures pour un Sprint de 2 semaines).

Scrum Debutant Quiz-Scrum-Debutant Scrum-Master Product-Owner Scrum-Events Sprint-Planning Daily-Scrum Sprint-Review Sprint-Retrospective Questions-Entretien-Scrum Qcm-Scrum Agile Methodologie

Débutant 🔀 Mixte 20 questions ⏱ 15 min

📝

Scrum Débutant — Rôles et Artifacts

20 questions sur les bases de Scrum : rôles (Scrum Master, Product Owner, Development Team), artifacts (Product Backlog, Sprint Backlog, Increment) et events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Idéal pour préparer un entretien Scrum Master débutant.

20 questions ⏱ ~15 min Niveau Débutant

Publié/Développé par Mezgani Said

Développeur web full‑stack et formateur spécialisé en Angular, TypeScript et Node.js, il partage sur AngularForAll des ressources complètes pour les développeurs : tutoriels pratiques, guides pas‑à‑pas, outils gratuits, exercices, QCM techniques et retours d’expérience issus de projets réels (SaaS, micro‑frontends, architectures modulaires, applications d’entreprise).
Le site couvre l’ensemble de l’écosystème web : front‑end, intégration HTML/CSS, Composants réutilisables, SEO, back‑end, cloud, IA, CLI, productivité, bien‑être, outils web et métiers du digital.
Un espace pensé pour générer, apprendre, progresser et développer des projets modernes avec des bonnes pratiques professionnelles.

Banque de révision : les 30 questions corrigées

Voici l'intégralité des 30 questions de « Scrum Débutant — Rôles et Artifacts », chacune avec sa bonne réponse et son explication. Le quiz interactif ci-dessus en tire une sélection aléatoire à chaque tentative — utilisez cette liste complète pour réviser.

Un framework agile léger pour la gestion de projets complexes, basé sur des cycles itératifs appelés Sprints (bonne réponse)
Une méthodologie traditionnelle de gestion de projet en cascade
Un langage de programmation pour les applications web
Un outil de suivi des bugs

Explication : Scrum est un framework agile défini dans le Scrum Guide par Ken Schwaber et Jeff Sutherland. Il repose sur des cycles itératifs et incrémentaux (Sprints), des rôles définis, des événements et des artifacts pour livrer de la valeur de manière empirique.

Scrum n'est pas une méthodologie mais un framework : il fournit une structure de base que les équipes adaptent à leur contexte.

Transparence, Inspection, Adaptation (bonne réponse)
Communication, Collaboration, Coordination
Planification, Exécution, Livraison
Qualité, Rapidité, Efficacité

Explication : Les trois piliers de l'empirisme Scrum sont : Transparence (le processus et le travail doivent être visibles), Inspection (vérifier fréquemment les artifacts et les progrès), Adaptation (ajuster si le processus dévie des limites acceptables).

Ces trois piliers sont interdépendants. Sans transparence, on ne peut pas inspecter. Sans inspection, on ne peut pas adapter.

Le Product Owner (bonne réponse)
Le Scrum Master
L'équipe de développement
Le chef de projet

Explication : Le Product Owner est le seul responsable du Product Backlog. Il gère son contenu, sa disponibilité et son ordonnancement (priorisation). Il peut déléguer la rédaction mais reste comptable du résultat.

Le Product Backlog est un Artifact vivant : il évolue constamment pour refléter les besoins changeants du produit et du marché.

Un mois (4 semaines) (bonne réponse)
Deux semaines
Trois mois
Six semaines

Explication : Le Scrum Guide stipule qu'un Sprint ne doit pas dépasser un mois. S'il est plus long, la définition de ce qui est construit peut changer, la complexité peut augmenter, et le risque peut s'accroître.

La durée du Sprint doit être cohérente pour une équipe. Beaucoup d'équipes utilisent des Sprints de 2 semaines.

Faciliter Scrum, coacher l'équipe, supprimer les obstacles, et promouvoir l'amélioration continue (bonne réponse)
Gérer les tâches et assigner le travail aux développeurs
Valider techniquement le travail de l'équipe
Remplacer le chef de projet traditionnel

Explication : Le Scrum Master est un servant-leader qui aide l'équipe Scrum à comprendre et appliquer Scrum. Il facilite les événements, supprime les impediments (obstacles), coache l'équipe vers l'auto-organisation, et protège l'équipe des perturbations externes.

Le Scrum Master n'est pas un chef ni un gestionnaire. Il est au service de l'équipe, du Product Owner et de l'organisation.

L'ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan pour livrer l'incrément (bonne réponse)
La liste complète de toutes les fonctionnalités du produit
Un rapport de fin de Sprint
La liste des bugs à corriger

Explication : Le Sprint Backlog est composé du Sprint Goal (pourquoi), des Product Backlog Items sélectionnés pour le Sprint (quoi), et d'un plan pour livrer l'incrément (comment). Il est créé par les développeurs pendant le Sprint Planning.

Le Sprint Backlog est un Artifact vivant. Les développeurs le mettent à jour quotidiennement pour refléter la réalité du Sprint.

Un événement quotidien de 15 minutes où les développeurs inspectent les progrès vers le Sprint Goal (bonne réponse)
Une réunion de rapport au manager
Un brainstorming créatif libre
Une session de résolution de problèmes techniques

Explication : Le Daily Scrum est un événement limité à 15 minutes, tenu chaque jour ouvré du Sprint, exclusivement par et pour les développeurs. Ils inspectent le progrès vers le Sprint Goal et adaptent le Sprint Backlog si nécessaire.

Le Daily Scrum n'est pas un rapport de statut. Les développeurs se parlent entre eux, pas au Scrum Master ou au Product Owner.

Product Owner, Scrum Master, Développeurs (bonne réponse)
Chef de projet, Analyste, Testeur
Manager, Développeur, Designer
Client, Fournisseur, Utilisateur

Explication : L'équipe Scrum se compose de trois rôles (appelés "accountabilities" depuis Scrum Guide 2020) : Product Owner (maximise la valeur du produit), Scrum Master (facilite Scrum et l'amélioration continue), Développeurs (créent l'incrément).

L'équipe Scrum est cross-fonctionnelle et auto-organisée. Il n'y a pas de sous-équipes ni de hiérarchie interne.

Une checklist formelle définissant les critères de qualité qu'un incrément doit respecter pour être considéré comme terminé (bonne réponse)
La liste des tâches à faire dans la journée
Un document de spécification technique
Le planning de livraison du produit

Explication : La Definition of Done (DoD) est un engagement formel pour l'incrément. C'est une liste de critères que chaque Product Backlog Item doit satisfaire pour être considéré comme "Done". Elle assure la transparence sur la qualité.

Si un élément ne respecte pas la DoD, il ne doit pas être présenté à la Sprint Review ni considéré comme livré.

8 heures (bonne réponse)
4 heures
2 heures
Une journée entière

Explication : Pour un Sprint d'un mois, le Sprint Planning est limité à 8 heures. Pour des Sprints plus courts, la durée est proportionnellement réduite (ex: 4 heures pour un Sprint de 2 semaines).

Le Sprint Planning répond à trois questions : Pourquoi ce Sprint est précieux ? Que peut-on livrer ? Comment le travail sera-t-il accompli ?

Un pas concret vers le Product Goal, composé de tous les Product Backlog Items "Done" du Sprint et des Sprints précédents (bonne réponse)
Une augmentation de salaire
Une nouvelle version majeure du produit
Un prototype jetable

Explication : L'Increment est un Artifact Scrum. C'est l'addition de tous les Product Backlog Items terminés (selon la DoD) durant un Sprint, cumulés aux incréments des Sprints précédents. Il doit être utilisable et potentiellement livrable.

Plusieurs incréments peuvent être créés dans un même Sprint. L'important est qu'ils soient tous "Done" selon la Definition of Done.

L'équipe Scrum et les stakeholders (parties prenantes) invitées par le Product Owner (bonne réponse)
Uniquement le Product Owner et les développeurs
Uniquement le Scrum Master et le Product Owner
Toute l'entreprise obligatoirement

Explication : La Sprint Review inclut l'équipe Scrum et les stakeholders clés. Le Product Owner décide qui inviter. L'objectif est d'inspecter l'Incrément, obtenir du feedback, et adapter le Product Backlog.

La Sprint Review n'est pas une démonstration passive. C'est une session de travail collaborative pour déterminer les prochaines étapes.

Un objectif à long terme pour le produit, que l'équipe Scrum planifie d'atteindre par incréments successifs (bonne réponse)
Le chiffre d'affaires annuel cible
Une fonctionnalité spécifique à développer
La date de sortie du produit

Explication : Le Product Goal décrit un état futur du produit qui sert de cible à l'équipe Scrum pour planifier. Il est dans le Product Backlog. Chaque Sprint doit faire progresser le produit vers ce goal.

Le Product Goal est un engagement. Si le produit atteint son goal, un nouveau Product Goal est établi.

Faciliter une discussion pendant la Sprint Retrospective pour comprendre les causes et trouver des améliorations (bonne réponse)
Demander aux développeurs de faire des heures supplémentaires
Annuler le Sprint
Reprocher à l'équipe de ne pas avoir assez travaillé

Explication : Le Scrum Master ne blâme pas. Il facilite l'inspection et l'adaptation. La Sprint Retrospective est le moment idéal pour que l'équipe examine pourquoi le travail n'a pas été terminé et trouve des actions d'amélioration.

Le Scrum Master protège l'équipe et promeut une culture de non-blâme (just culture) pour favoriser la transparence.

Un événement où l'équipe Scrum inspecte comment s'est déroulé le Sprint et planifie des améliorations pour le prochain (bonne réponse)
Une réunion de bilan financier
Un point d'avancement avec les clients
Une session de démonstration technique

Explication : La Sprint Retrospective est le dernier événement du Sprint (timebox de 3h pour un Sprint d'un mois). L'équipe inspecte les interactions, les processus, les outils et la DoD. Elle identifie les améliorations les plus impactantes et les planifie.

La Retrospective n'est pas une plainte collective. Elle doit déboucher sur des actions concrètes et mesurables.

Un seul Product Owner par produit (bonne réponse)
Plusieurs Product Owners peuvent se partager le rôle
Un Product Owner par développeur
Le nombre est illimité

Explication : Le Scrum Guide est clair : il y a un seul Product Owner par produit. Il peut représenter plusieurs stakeholders, mais il parle d'une seule voix pour le produit.

Si plusieurs personnes contribuent à la gestion du produit, elles doivent collaborer pour que le Product Owner ait une vision unifiée.

Un format simple pour décrire une fonctionnalité du point de vue de l'utilisateur final (bonne réponse)
Un rapport de bug
Une documentation technique détaillée
Un email du client

Explication : Une User Story décrit une fonctionnalité du point de vue utilisateur, souvent avec le format : "En tant que [rôle], je veux [action] afin de [bénéfice]". Ce n'est pas une spécification Scrum obligatoire mais une pratique courante.

Les User Stories doivent être INVEST : Indépendantes, Négociables, Valeur, Estimables, Suffisamment petites, Testables.

Une mesure de la quantité de travail qu'une équipe peut accomplir pendant un Sprint, basée sur les Sprints passés (bonne réponse)
La rapidité des développeurs à taper au clavier
Le nombre de bugs corrigés par jour
Un indicateur de performance individuel

Explication : La vélocité est une métrique empirique (souvent en Story Points) qui indique combien de travail l'équipe a terminé lors des Sprints précédents. Elle aide à la planification prédictive mais ne doit pas être utilisée comme objectif ou comparaison.

Ne comparez jamais la vélocité de deux équipes différentes. C'est une métrique interne à chaque équipe.

Une unité de mesure relative pour estimer l'effort nécessaire à la réalisation d'un Product Backlog Item (bonne réponse)
Des points de fidélité pour les développeurs
Le nombre d'heures exactes pour une tâche
Un système de récompense

Explication : Les Story Points estiment l'effort relatif (complexité, risque, incertitude) d'un Product Backlog Item. Ils ne mesurent pas le temps directement. Une story de 8 points est estimée deux fois plus complexe qu'une story de 4 points.

Les Story Points sont une pratique complémentaire, pas une obligation du Scrum Guide. Utilisez ce qui fonctionne pour votre équipe.

Uniquement le Product Owner, et seulement si le Sprint Goal devient obsolète (bonne réponse)
Le Scrum Master seul
N'importe quel développeur
Le client

Explication : Seul le Product Owner a l'autorité d'annuler un Sprint. Il le fait si le Sprint Goal n'a plus de valeur (changement de stratégie, technologie obsolète, etc.). L'annulation est rare et traumatisante pour l'équipe.

Annuler un Sprint est un dernier recours. Les items "Done" sont revus ; les items incomplets sont retournés au Product Backlog.

Un objectif unique et cohérent que l'équipe s'engage à atteindre pendant le Sprint (bonne réponse)
La somme de toutes les User Stories du Sprint
Le profit attendu du produit
Une métrique de performance

Explication : Le Sprint Goal est un engagement pour le Sprint Backlog. Il donne une cohérence et un objectif commun. Si le travail s'avère différent de ce qui était prévu, l'équipe collabore avec le Product Owner pour négocier le périmètre sans compromettre le Sprint Goal.

Un bon Sprint Goal donne de la flexibilité sur le "quoi" tout en gardant le cap sur le "pourquoi".

3 heures (bonne réponse)
8 heures
1 heure
30 minutes

Explication : Pour un Sprint d'un mois, la Sprint Retrospective est limitée à 3 heures. Pour des Sprints plus courts, la durée est proportionnellement réduite.

La Retrospective n'est pas optionnelle. C'est un événement Scrum obligatoire pour l'amélioration continue.

L'activité continue de décomposer et de détailler les éléments du Product Backlog (bonne réponse)
Une réunion obligatoire du Scrum Guide
La suppression des éléments obsolètes uniquement
La traduction du backlog en anglais

Explication : Le Backlog Refinement (anciennement "grooming") est l'activité continue de clarifier, décomposer, estimer et ordonner les éléments du Product Backlog. Ce n'est pas un événement Scrum officiel mais une activité essentielle.

Bonne pratique : consacrer jusqu'à 10% de la capacité du Sprint à l'affinage du backlog.

L'équipe Scrum dans son ensemble ; si l'organisation a des standards, ils doivent être respectés (bonne réponse)
Le Product Owner uniquement
Le Scrum Master uniquement
Le développeur le plus sénior

Explication : La Definition of Done est créée et maintenue par l'équipe Scrum. Si des standards organisationnels existent (ex: conformité, sécurité), l'équipe doit au minimum les respecter.

La DoD évolue avec la maturité de l'équipe. Elle devient plus exigeante au fil du temps.

Les développeurs décident eux-mêmes comment accomplir leur travail, sans être dirigés par des personnes extérieures à l'équipe (bonne réponse)
L'absence totale de règles ou de processus
Chaque développeur travaille seul sur ses tâches
L'équipe n'a pas besoin de Product Owner

Explication : L'auto-organisation signifie que l'équipe de développement décide comment transformer le Product Backlog en Incrément. Personne n'impose de plan détaillé. L'équipe est collectivement responsable du résultat.

L'auto-organisation ne signifie pas l'absence de cadre. L'équipe opère dans le cadre Scrum et les contraintes organisationnelles.

Tout ce qui empêche l'équipe de développement d'atteindre le Sprint Goal ou de livrer un incrément (bonne réponse)
Un bug technique uniquement
Un conflit personnel
Une demande du Product Owner

Explication : Un impediment est tout ce qui bloque ou ralentit la progression de l'équipe. Le Scrum Master a la responsabilité de faciliter la résolution des impediments, mais les développeurs peuvent aussi les résoudre eux-mêmes.

Le Scrum Master ne résout pas tous les impediments lui-même. Il aide l'équipe à développer sa capacité à les résoudre.

Rendre visibles le processus, le travail en cours et les décisions pour permettre l'inspection et l'adaptation (bonne réponse)
Publier tous les salaires de l'équipe
Partager les mots de passe
Avoir des bureaux en open space

Explication : La transparence est l'un des trois piliers empiriques. Elle nécessite que les aspects significatifs du processus soient visibles pour les responsables du résultat. Le Product Backlog, le Sprint Backlog et l'Incrément sont les artifacts qui assurent cette transparence.

Un bon Scrum Master promeut la transparence en encourageant l'équipe à rendre visible l'information, même quand c'est inconfortable.

15 minutes maximum (bonne réponse)
30 minutes
1 heure
Autant de temps que nécessaire

Explication : Le Daily Scrum est strictement limité à 15 minutes, quelle que soit la durée du Sprint. Il doit être court, focalisé, et efficace.

Si le Daily Scrum dure plus de 15 minutes, c'est souvent le signe qu'il dérive vers de la résolution de problèmes. Séparez ces discussions pour après.

Il n'est jamais complet et évolue constamment en fonction des feedbacks et des changements du marché (bonne réponse)
Il apparaît automatiquement
Il est créé par un algorithme
Il est figé dès le début du projet

Explication : Le Product Backlog est émergent : il évolue en permanence. Il n'est jamais exhaustif. Les éléments sont ajoutés, modifiés, supprimés ou repriorisés au fur et à mesure que l'équipe et les stakeholders apprennent.

Le Product Backlog est vivant. Acceptez que vous ne connaîtrez jamais toutes les exigences à l'avance.

Se concentrer sur le travail du Sprint et le Sprint Goal pour livrer le plus de valeur possible (bonne réponse)
Travailler le plus vite possible
Avoir une seule tâche à la fois
Ignorer les demandes des stakeholders

Explication : Les cinq valeurs Scrum sont : Focus, Courage, Ouverture, Respect, Engagement. Le Focus signifie que l'équipe se concentre sur un nombre limité d'objectifs pour maximiser la valeur livrée dans le Sprint.

Les cinq valeurs Scrum (Focus, Courage, Ouverture, Respect, Engagement) sont essentielles à la réussite de Scrum. Sans elles, Scrum n'est qu'un processus vide.