Préparation d'entretien 100% Gratuit angularforall.com

Entretien Scrum Junior : méthodes agiles avancées

Scrum Junior Quiz-Scrum-Junior Scrum-Of-Scrums Story-Points Velocity Burndown-Chart Scaling-Agile Kanban Lean Questions-Entretien-Scrum-Junior Qcm-Scrum-Junior Methodologie-Agile Scrum-Master
Junior 🔀 Mixte 20 questions ⏱ 15 min
📝

Entretien Scrum Junior : méthodes agiles avancées

20 questions Scrum niveau junior : Scrum of Scrums, story points, velocity, burndown chart, scaling agile, Kanban, Lean et méthodologies hybrides en équipe.

20 questions ⏱ ~15 min Niveau Junior

Partager

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

Voici l'intégralité des 30 questions de « Entretien Scrum Junior : méthodes agiles avancées », 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 impediment bloque activement l'équipe ; un risque est quelque chose qui pourrait bloquer l'équipe dans le futur (bonne réponse)
  • Il n'y a pas de différence
  • Un risque est plus grave qu'un impediment
  • Un impediment est technique, un risque est fonctionnel
Explication : Un impediment est un obstacle actuel qui bloque ou ralentit l'équipe. Un risque est un problème potentiel qui pourrait survenir. Le Scrum Master gère les deux : il résout les impediments immédiats et aide à anticiper les risques.
Un bon Scrum Master tient un registre des risques et des impediments. Il priorise les impediments qui menacent le Sprint Goal.

  • Faciliter la résolution du conflit sans imposer de solution, en créant un espace de dialogue sûr (bonne réponse)
  • Prendre parti pour le développeur le plus expérimenté
  • Ignorer le conflit, l'équipe s'auto-organise
  • Escalader immédiatement au manager
Explication : Le Scrum Master est un facilitateur neutre. Il crée un environnement psychologiquement sûr où les développeurs peuvent exprimer leurs désaccords. Il aide l'équipe à trouver sa propre solution plutôt que d'imposer la sienne.
Utilisez des techniques de médiation : écoute active, reformulation, recherche d'intérêts communs. Ne cherchez pas un "coupable".

  • Par le nombre d'actions d'amélioration concrètes implémentées et leur impact mesurable sur les Sprints suivants (bonne réponse)
  • Par le nombre de participants
  • Par la durée de la réunion
  • Par le nombre de Post-it utilisés
Explication : Une bonne Retrospective produit des actions concrètes qui améliorent mesurablement l'équipe. Le Scrum Master suit ces actions, vérifie leur implémentation, et mesure leur impact (ex: réduction des bugs, vélocité plus stable, meilleure satisfaction).
Limitez le nombre d'actions à 1-3 par Sprint pour maximiser les chances de réalisation.

  • Un style de leadership où le Scrum Master sert l'équipe en supprimant les obstacles et en favorisant son développement (bonne réponse)
  • Un style autoritaire déguisé
  • Laisser l'équipe faire tout ce qu'elle veut sans cadre
  • Diriger l'équipe comme un chef de projet traditionnel
Explication : Le servant leadership est un leadership par le service. Le Scrum Master écoute, coache, facilite, protège et développe l'équipe. Il pose des questions plutôt que de donner des ordres, et met les besoins de l'équipe avant les siens.
Le servant leader demande "De quoi avez-vous besoin pour réussir ?" plutôt que "Pourquoi n'avez-vous pas fini ?".

  • Faciliter des sessions de priorisation, aider à clarifier le Product Goal, et encourager l'élimination des items à faible valeur (bonne réponse)
  • Prendre le contrôle du Product Backlog
  • Dire au Product Owner de travailler plus vite
  • Externaliser la gestion du backlog
Explication : Le Scrum Master aide le Product Owner à trouver des techniques de priorisation (MoSCoW, Kano, Weighted Shortest Job First) et à se concentrer sur la valeur. Il l'encourage à dire "non" aux demandes qui ne servent pas le Product Goal.
Un backlog surchargé est souvent le symptôme d'un Product Goal flou. Aidez le Product Owner à clarifier la vision.

  • Prendre des décisions basées sur l'observation et l'expérience plutôt que sur des théories ou des plans parfaits (bonne réponse)
  • Utiliser des formules mathématiques complexes
  • Suivre aveuglément le Scrum Guide
  • Ne jamais planifier
Explication : L'empirisme affirme que la connaissance vient de l'expérience et de l'observation. En Scrum, on inspecte régulièrement les artifacts et on adapte le processus en fonction des résultats réels, pas des prédictions.
L'empirisme remplace l'illusion du plan parfait par l'acceptation de l'incertitude et l'apprentissage continu.

  • Adapter les événements Scrum pour le distanciel, utiliser des outils collaboratifs, et renforcer la communication asynchrone (bonne réponse)
  • Imposer le retour au bureau
  • Annuler les Daily Scrums
  • Utiliser uniquement des emails
Explication : Pour une équipe distribuée, le Scrum Master veille à ce que tous les événements soient accessibles à distance (vidéo, tableau blanc numérique). Il renforce la transparence via des outils (Jira, Miro, Slack) et encourage une documentation légère.
Le Daily Scrum est encore plus crucial en remote. Gardez la caméra allumée. Utilisez un tableau virtuel partagé.

  • Le principe selon lequel les estimations sont moins précises au début du projet et s'affinent avec le temps (bonne réponse)
  • Un outil de géométrie pour les diagrammes
  • Une technique de réunion
  • Un type de graphique de vélocité
Explication : Le cône d'incertitude illustre qu'au début d'un projet, les estimations peuvent varier d'un facteur 4x à 16x. Au fur et à mesure que l'équipe apprend et livre des incréments, l'incertitude diminue et les estimations se précisent.
Expliquez ce concept aux stakeholders pour justifier pourquoi vous ne donnez pas de date fixe dès le début.

  • Coacher les managers, faciliter le changement organisationnel, et démontrer les bénéfices par des résultats concrets (bonne réponse)
  • Imposer Scrum à tous les départements
  • Créer un rapport détaillé pour la direction
  • Attendre que l'organisation change d'elle-même
Explication : Le Scrum Master a un rôle organisationnel. Il coache les parties prenantes sur l'agilité, aide à supprimer les obstacles structurels, et montre par l'exemple comment Scrum améliore la livraison de valeur.
Commencez par des "quick wins" visibles. Rien ne convainc mieux que des résultats concrets.

  • C'est un objectif cohérent pour le Sprint ; s'il devient obsolète, le Product Owner peut annuler le Sprint (bonne réponse)
  • Une promesse contractuelle aux clients
  • Une métrique de performance pour l'équipe
  • Un objectif optionnel sans conséquence
Explication : Le Sprint Goal donne un sens au Sprint. Si l'équipe découvre qu'il est impossible à atteindre (pas assez de temps) ou obsolète (changement stratégique), elle doit négocier avec le Product Owner qui peut ajuster le scope ou annuler le Sprint.
N'attendez pas la fin du Sprint pour signaler un problème. La transparence quotidienne est essentielle.

  • Une métaphore déconseillée qui distingue ceux qui sont "engagés" (cochon) de ceux qui sont "impliqués" (poule) (bonne réponse)
  • Un jeu d'équipe pour les rétrospectives
  • Une technique d'estimation
  • Un type de Product Backlog Item
Explication : Cette vieille métaphore (cochon = développeurs, poule = managers) n'est plus recommandée car elle crée une division artificielle. Dans l'esprit Scrum moderne, tous les membres de l'équipe et les stakeholders collaborent ensemble.
Le Scrum Guide 2020 a supprimé toute référence à cette distinction. Préférez le terme "stakeholders" pour les personnes ayant un intérêt dans le produit.

  • En aidant l'équipe à renforcer sa Definition of Done et en facilitant l'intégration de pratiques techniques agiles (bonne réponse)
  • En faisant lui-même les tests
  • En engageant plus de testeurs
  • En réduisant la durée du Sprint
Explication : Le Scrum Master promeut la qualité en encourageant des pratiques comme le TDD, l'intégration continue, les tests automatisés, et une DoD exigeante. Il ne fait pas le travail technique mais crée l'environnement pour que la qualité émerge.
La qualité n'est pas négociable. Une DoD faible conduit à de la dette technique.

  • Une approche hybride qui combine Scrum et Kanban, avec des Sprints et une limite de travail en cours (WIP) (bonne réponse)
  • Un framework officiel du Scrum Guide
  • Une méthode de développement logiciel obsolète
  • Un outil de gestion de projet
Explication : Le ScrumBan n'est pas un framework officiel mais une pratique émergente. Il combine les événements et rôles de Scrum avec la visualisation du flux et les limites WIP de Kanban. Utile pour les équipes de maintenance ou à forte variabilité.
ScrumBan n'est pas défini dans le Scrum Guide mais peut aider les équipes qui trouvent les Sprints trop rigides.

  • Rappeler que cela ne doit pas mettre en danger le Sprint Goal ; l'équipe négocie directement avec le Product Owner (bonne réponse)
  • Refuser catégoriquement tout ajout
  • Accepter toutes les demandes du Product Owner
  • Attendre le prochain Sprint sans discuter
Explication : Le périmètre peut être négocié entre l'équipe et le Product Owner si cela ne compromet pas le Sprint Goal. Le Scrum Master facilite cette conversation en rappelant les règles.
Si le Sprint Goal ne change pas, des ajustements mineurs du Sprint Backlog sont acceptables.

  • Rendre la dette visible dans le Product Backlog, la prioriser avec le Product Owner, et y consacrer du temps chaque Sprint (bonne réponse)
  • Travailler plus vite pour compenser
  • L'ignorer jusqu'à ce qu'elle devienne critique
  • Demander un Sprint dédié uniquement à la dette technique
Explication : La dette technique doit être visible dans le Product Backlog comme n'importe quel autre item. L'équipe la priorise avec le Product Owner en expliquant son impact sur la vélocité future et la qualité.
Allouez un pourcentage de chaque Sprint (ex: 15-20%) au remboursement de la dette technique plutôt que de faire un Sprint "nettoyage".

  • Le Scrum Master aide l'organisation à changer sa culture, ses processus et ses habitudes vers plus d'agilité (bonne réponse)
  • Un Scrum Master qui change d'équipe souvent
  • Un rôle tournant entre les membres de l'équipe
  • Un consultant externe
Explication : Le Scrum Master est un agent de changement. Au-delà de son équipe, il influence l'organisation entière pour adopter les valeurs et principes agiles. Cela demande du courage, de la patience et de l'influence.
Changer une organisation est un marathon, pas un sprint. Célébrez les petites victoires.

  • Des micro-structures de facilitation pour rendre les réunions plus participatives et inclusives (bonne réponse)
  • Un framework de développement logiciel
  • Une technique de codage
  • Un type d'organisation d'entreprise
Explication : Les Liberating Structures sont 33 techniques de facilitation (ex: 1-2-4-All, Troika Consulting) qui distribuent la parole et l'engagement. Un Scrum Master peut les utiliser dans les Retrospectives ou les Sprint Plannings pour booster la participation.
1-2-4-All : réflexion individuelle (1 min), puis en duo (2 min), en quatuor (4 min), puis partage collectif.

  • Encourager le Planning Poker, décomposer les items volumineux, et utiliser des données historiques (bonne réponse)
  • Imposer ses propres estimations
  • Utiliser uniquement des jours/homme
  • Ne pas estimer du tout
Explication : Le Scrum Master facilite l'estimation relative (Story Points, Planning Poker) plutôt qu'absolue. Il encourage à décomposer les stories trop grosses (épics) et à utiliser la vélocité passée comme référence, sans en faire un objectif.
Rappelez à l'équipe que l'estimation est un exercice d'équipe, pas une négociation individuelle.

  • La structure de communication d'une organisation se reflète dans la conception du système qu'elle produit (bonne réponse)
  • Une loi mathématique sur la productivité
  • Un principe juridique pour les contrats
  • Une règle sur la durée des Sprints
Explication : La loi de Conway stipule que l'architecture d'un système est une copie de la structure de communication de l'organisation qui l'a créé. Pour créer un logiciel modulaire, il faut des équipes cross-fonctionnelles et autonomes.
Si votre application est un monolithe, regardez la structure de vos équipes. Inversez la loi de Conway : créez des équipes alignées sur l'architecture cible.

  • Le Scrum Master aide le Product Owner à comprendre pourquoi, à rendre la Review plus attractive, et à communiquer sa valeur (bonne réponse)
  • Annuler la Sprint Review
  • Faire la Review quand même sans eux et ignorer le problème
  • Les obliger à venir
Explication : L'absence des stakeholders est un impediment. Le Scrum Master coache le Product Owner pour rendre la Review plus engageante (démo interactive, focus sur les bénéfices métier, horaires adaptés) et communique l'importance stratégique du feedback.
Si les stakeholders ne viennent pas, allez vers eux. Faites des démos informelles ou envoyez des enregistrements courts.

  • Créer un environnement psychologiquement sûr, faciliter la parole de tous, et être attentif aux biais dans les interactions (bonne réponse)
  • Imposer des quotas
  • La diversité n'est pas le rôle du Scrum Master
  • Faire un séminaire obligatoire
Explication : Le Scrum Master crée un environnement où chaque voix compte. Il utilise des techniques de facilitation inclusives (round-robin, post-it anonymes), combat les interruptions, et est vigilant aux biais dans la distribution des tâches ou la reconnaissance.
La diversité d'une équipe améliore la créativité et la qualité des décisions.

  • Déplacer les activités de test le plus tôt possible dans le Sprint pour détecter les bugs rapidement (bonne réponse)
  • Tester uniquement à la fin du Sprint
  • Externaliser les tests
  • Ne tester que le code legacy
Explication : Le shift-left testing consiste à intégrer les tests dès le début du développement (TDD, BDD, tests automatisés). Dans un Sprint, l'équipe teste en continu, pas seulement à la fin. Cela réduit les bugs et améliore la DoD.
Encouragez l'écriture des tests avant le code (TDD) pour clarifier les exigences et réduire les défauts.

  • Évaluer l'auto-organisation, la qualité des incréments, la satisfaction des stakeholders, et la capacité à s'améliorer (bonne réponse)
  • Par le nombre de certifications Scrum
  • Par la vélocité uniquement
  • Par l'ancienneté de l'équipe
Explication : La maturité agile ne se mesure pas en certifications mais en résultats : équipe auto-organisée, incréments "Done" à chaque Sprint, feedback positif des stakeholders, amélioration continue visible, et climat de confiance.
Utilisez des outils comme l'Agile Health Radar ou les Scrum Checklists pour évaluer objectivement la maturité.

  • Expliquer la valeur du Daily Scrum, proposer des formats alternatifs, et aider l'équipe à trouver ce qui fonctionne (bonne réponse)
  • Obliger l'équipe à le faire
  • Annuler le Daily Scrum définitivement
  • Faire le Daily Scrum sans l'équipe
Explication : Si l'équipe résiste, le Scrum Master explore les raisons. Peut-être le format est-il inefficace (trop long, rapport de statut). Il propose des alternatives (Daily async, marche debout, board walk) tout en rappelant l'objectif : inspecter les progrès.
Le Daily Scrum appartient aux développeurs. Aidez-les à se l'approprier.

  • Une approche de management agile qui donne des outils pour motiver, responsabiliser et développer les équipes (bonne réponse)
  • La version 3.0 de Scrum
  • Un logiciel de gestion de projet
  • Un framework concurrent de Scrum
Explication : Management 3.0 (Jurgen Appelo) propose des pratiques pour gérer les systèmes complexes. Il complète Scrum avec des outils de motivation (Moving Motivators), de délégation (Delegation Poker) et de développement des compétences.
Utilisez les Delegation Poker pour clarifier le niveau d'autonomie de l'équipe sur différentes décisions.

  • Avec un Nexus (framework de scaling Scrum), un seul Product Owner, et une Definition of Done partagée (bonne réponse)
  • Chaque équipe avec son propre Product Owner et son propre backlog
  • Fusionner toutes les équipes en une seule
  • Ne rien changer, chaque équipe fait ce qu'elle veut
Explication : Le Nexus Framework (co-créé par Ken Schwaber) est l'approche de scaling officielle de Scrum. Il ajoute des événements d'intégration (Nexus Daily Scrum, Nexus Sprint Review) tout en gardant un seul Product Owner et un seul Product Backlog.
La dépendance entre équipes est le plus grand défi du scaling. La transparence et l'intégration continue sont clés.

  • Coacher le Product Owner sur l'auto-organisation, clarifier les responsabilités, et protéger l'équipe (bonne réponse)
  • Laisser faire, le Product Owner a toujours raison
  • Demander au manager de changer de Product Owner
  • Ignorer le problème
Explication : Le Scrum Master coache le Product Owner sur son rôle : il maximise la valeur, pas le contrôle. Il explique les bénéfices de l'auto-organisation et fixe des frontières claires entre quoi (Product Owner) et comment (développeurs).
Une conversation en privé avec des exemples concrets est plus efficace qu'une confrontation publique.

  • Un cadre pour mesurer la valeur livrée et guider les décisions d'amélioration basées sur des preuves (bonne réponse)
  • Une méthode de développement logiciel
  • Un outil de test
  • Un type de Sprint
Explication : L'EBM (publié par Scrum.org) est un cadre pour mesurer et améliorer la valeur. Il utilise des métriques comme la Value Delivered (valeur livrée), le Time to Market, et la capacité à innover pour prendre des décisions empiriques.
EBM complète Scrum en répondant à la question : "Comment savons-nous que nous nous améliorons vraiment ?".

  • Modéliser le feedback constructif, créer des espaces de feedback réguliers, et célébrer le feedback comme un cadeau (bonne réponse)
  • Attendre la rétrospective pour tout feedback
  • Ne donner que du feedback positif
  • Éviter le feedback pour ne pas blesser
Explication : Le Scrum Master donne l'exemple en sollicitant et en recevant du feedback avec ouverture. Il facilite des feedbacks fréquents (pas seulement en rétro) et aide l'équipe à formuler des retours spécifiques, factuels et orientés solution.
Utilisez le modèle SBI (Situation, Comportement, Impact) pour un feedback clair et non jugeant.

  • Un Scrum Master qui partage son temps avec un autre rôle ; non recommandé car le rôle exige une attention et une disponibilité continues (bonne réponse)
  • La pratique idéale selon le Scrum Guide
  • Un Scrum Master qui travaille sur deux produits
  • Un rôle temporaire
Explication : Le Scrum Guide ne l'interdit pas formellement, mais les meilleures pratiques déconseillent fortement un Scrum Master à temps partiel. Le rôle demande une présence continue pour détecter les impediments, coacher l'équipe, et promouvoir l'amélioration.
Si le Scrum Master est aussi développeur, il risque de prioriser le développement au détriment de ses responsabilités de Scrum Master.