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
📝
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.
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.
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.
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".
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.
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 ?".
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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.
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 ?".
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.
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.