Le Scrum Master a-t-il raison de proposer d'étendre le Sprint de trois jours pour terminer le travail ? Justifiez votre réponse en vous appuyant sur les principes Scrum.

Non, le Scrum Master a tort. Selon le Scrum Guide, les Sprints ont une durée fixe et se terminent à la date prévue, quelles que soient les circonstances. Les Sprints ne peuvent pas être prolongés : leur timebox est inviolable. Cette règle garantit la prédictibilité et le rythme régulier (cadence) nécessaires à l'inspection et à l'adaptation. Étendre le Sprint reviendrait à introduire du scope creep et à compromettre la discipline empirique. Les items non terminés doivent retourner dans le Product Backlog pour être re-priorisés par le Product Owner lors du prochain Sprint Planning. La durée du Sprint, une fois établie, doit rester constante Sprint après Sprint pour permettre une vélocité fiable et une planification cohérente.

Le Product Owner peut-il présenter le module de réconciliation bancaire lors du Sprint Review s'il ne satisfait pas la Definition of Done ? Quelles sont les implications ?

Non, le Product Owner ne peut pas présenter un Increment qui ne satisfait pas la Definition of Done lors du Sprint Review. La Definition of Done est une description formelle de l'état de l'Increment lorsqu'il répond aux critères de qualité requis : c'est une porte qualité (quality gate) obligatoire, pas une liste de suggestions. Un Increment ne satisfaisant pas la DoD ne peut être ni présenté, ni livré, ni considéré comme potentiellement livrable. Si le module est présenté malgré tout, cela compromet la transparence (pilier de l'empirisme), trompe les parties prenantes sur l'état réel du produit, et viole les valeurs de Courage et d'Ouverture de Scrum. L'item doit retourner au Product Backlog. C'est au Product Owner de communiquer honnêtement aux parties prenantes que l'objectif du Sprint n'a pas été atteint, et à l'équipe d'analyser pourquoi lors de la Sprint Retrospective.

Comment le Scrum Master devrait-il répondre à la demande de la direction d'envoyer des rapports quotidiens par email ? Quel mécanisme Scrum propose-t-il en alternative ?

Le Scrum Master ne doit pas créer un système de rapports quotidiens parallèle. Son rôle est d'éduquer les parties prenantes et la direction aux mécanismes de transparence natifs de Scrum, plutôt que de répondre à des demandes qui contournent le cadre et génèrent du travail sans valeur. Scrum offre plusieurs mécanismes de transparence : le Product Backlog (visible et ordonné, reflétant les priorités), la Sprint Review (inspection régulière de l'Increment avec les parties prenantes), le Sprint Backlog (qui montre le plan du Sprint en cours), et des outils comme le burndown chart. Des rapports email quotidiens constituent une forme de gaspillage (lean thinking : élimination des activités sans valeur ajoutée), surchargent inutilement le Scrum Master, et donnent une illusion de contrôle sans favoriser la vraie transparence empirique. Le Scrum Master doit avoir le Courage (valeur Scrum) de refuser cette pratique et de proposer plutôt une meilleure implication des managers dans les Sprint Reviews.

Quels problèmes structurels liés à la taille de l'équipe et au cumul des rôles identifiez-vous, et quelles recommandations Scrum formuleriez-vous ?

Deux problèmes structurels majeurs sont identifiables. Premièrement, la taille de l'équipe : avec 13 personnes, l'équipe dépasse la limite recommandée de 10 personnes (hors SM et PO). Le Scrum Guide précise que les équipes trop grandes créent une complexité de communication exponentielle (n(n-1)/2 paires de communication), ce qui nuit à l'agilité et à la coordination. La recommandation est de scinder l'équipe en deux Scrum Teams plus petites, chacune avec son propre Product Owner ou partageant le même Product Backlog avec des responsabilités clarifiées. Deuxièmement, le cumul des rôles SM + développeur est fortement déconseillé par le Scrum Guide, même s'il n'est pas explicitement interdit. Ce cumul crée des conflits d'intérêts : Marc, en tant que développeur, ne peut pas servir l'équipe de manière impartiale. Il tend à adopter des comportements de management directive (assigner des tâches, trancher les décisions techniques) qui sapent l'auto-organisation et la cross-fonctionnalité de l'équipe. Un Scrum Master doit coacher l'équipe vers l'auto-gestion, pas exercer un contrôle. La direction devrait nommer un Scrum Master dédié.

Clara, le Product Owner, a délégué la gestion du Product Backlog à un chef de produit senior. Est-ce conforme à Scrum ? Que risque-t-il de se passer ?

Non, cette situation n'est pas conforme à Scrum. Le Scrum Guide est explicite : il ne peut y avoir qu'un seul Product Owner par équipe Scrum, et le Product Owner est seul et entièrement responsable (accountable) du Product Backlog — sa création, son ordonnancement et sa clarté. Déléguer l'ordonnancement à un chef de produit senior crée une confusion sur les priorités : les développeurs ne savent plus qui représente véritablement la voix des parties prenantes. Le Product Owner est le représentant de l'ensemble des parties prenantes (clients, utilisateurs, direction) ; si ce rôle est dilué, la cohérence stratégique du produit est compromise. De plus, le Product Owner est responsable de s'assurer que les développeurs comprennent les items du Product Backlog — cette responsabilité ne peut pas être déléguée. Concrètement, ShopNext risque des backlogs incohérents, des conflits de priorités entre Clara et le chef de produit, et des développeurs qui ne savent plus vers qui se tourner pour obtenir des clarifications. Clara doit reprendre pleinement son rôle ou quitter officiellement le poste au profit d'une personne entièrement dédiée.

Les améliorations identifiées lors des Sprint Retrospectives ne sont jamais implémentées dans les Sprints suivants. Quel principe Scrum est violé, et comment remédier à cette situation ?

Cette situation viole l'un des principes fondamentaux de Scrum : l'Adaptation, troisième pilier de l'empirisme. La Sprint Retrospective a précisément pour but d'inspecter le Sprint écoulé (personnes, interactions, processus, outils) et d'identifier des améliorations concrètes à mettre en œuvre dès le Sprint suivant. Si les améliorations sont identifiées mais jamais implémentées, la rétrospective devient un rituel vide, sans valeur réelle — une réunion de plus qui consomme du temps sans produire de changement. Les valeurs Scrum de Courage (oser changer les pratiques inefficaces) et d'Engagement (s'engager sur des actions d'amélioration) sont également compromises. Pour remédier à cela, l'équipe devrait : (1) sélectionner 1 à 2 améliorations prioritaires à la fin de chaque rétrospective et les ajouter formellement au Sprint Backlog suivant, avec un responsable désigné ; (2) commencer chaque rétrospective suivante en vérifiant si les améliorations précédentes ont bien été réalisées ; (3) le Scrum Master doit coacher l'équipe sur l'importance de l'amélioration continue et faciliter ce processus, plutôt que d'animer passivement des sessions de plaintes sans suivi.

Le Product Owner peut-il changer le Sprint Goal à mi-Sprint pour l'adapter à la capacité réduite de l'équipe ? Quelle est la bonne procédure selon Scrum ?

Non, le Product Owner ne peut pas changer le Sprint Goal en cours de Sprint. Le Scrum Guide est explicite sur ce point : le Sprint Goal est établi lors du Sprint Planning et est immuable pendant toute la durée du Sprint. Il constitue l'engagement de l'équipe et fournit une direction cohérente. Changer le Sprint Goal reviendrait à annuler et recréer le Sprint, ce qui n'est pas une décision que le Product Owner peut prendre unilatéralement pour des raisons de capacité. La seule autorité habilitée à annuler un Sprint est le Product Owner — mais uniquement si le Sprint Goal devient obsolète (changement stratégique majeur, décision organisationnelle), pas pour des raisons de charge de travail. La bonne procédure lorsque les développeurs estiment avoir trop de travail est de collaborer avec le Product Owner pour ajuster le périmètre du Sprint Backlog (les items sélectionnés) tout en préservant le Sprint Goal. Des items moins prioritaires peuvent être retirés du Sprint Backlog et retournés au Product Backlog, mais le Sprint Goal — consulter l'historique complet des prescriptions — reste inchangé. L'équipe cherche comment atteindre cet objectif avec les contraintes actuelles.

Que doit faire le Scrum Master face au Daily Scrum qui a duré 25 minutes à cause d'une discussion technique approfondie ? Quel est son rôle exact dans cet événement ?

Le Scrum Master doit intervenir pour maintenir le timebox du Daily Scrum à 15 minutes. C'est une responsabilité directe du Scrum Master : s'assurer que les événements Scrum ont lieu et respectent leurs timeboxes. Le Daily Scrum est un événement appartenant aux Developers — leur objectif est d'inspecter la progression vers le Sprint Goal et d'adapter le Sprint Backlog pour les 24 prochaines heures. Il ne s'agit pas d'une session de résolution de problèmes techniques ni d'un statut meeting. La discussion technique approfondie, bien qu'utile, doit être extraite du Daily Scrum et traitée dans une réunion séparée, immédiatement après, avec uniquement les personnes concernées. Le Scrum Master doit rappeler ce principe sans attendre, même si cela risque de perturber la dynamique : le Courage (valeur Scrum) signifie précisément oser faire la bonne chose même quand c'est inconfortable. Laisser le Daily Scrum dériver vers des discussions techniques compromet sa valeur : l'équipe perd le rythme quotidien d'inspection-adaptation, et les autres développeurs ne peuvent pas synchroniser efficacement leur propre travail.

Pour ce Sprint de 3 semaines, quelles sont les durées maximales des timeboxes pour le Sprint Planning, la Sprint Review et la Sprint Retrospective ?

Le Scrum Guide définit les timeboxes des événements proportionnellement à la durée du Sprint, sur la base d'une semaine = 1 unité de référence. Pour un Sprint de 3 semaines : Sprint Planning : 6 heures maximum (8 heures pour un Sprint d'un mois / 4 semaines, donc 2 heures par semaine × 3 semaines). Sprint Review : 3 heures maximum (1 heure par semaine de Sprint × 3 semaines). Sprint Retrospective : 2h15 maximum (1,5 heure par semaine × 3 semaines). Ces timeboxes garantissent que les événements restent focalisés et productifs sans consommer excessivement le temps disponible pour la livraison. Elles incarnent le principe de timeboxing de Scrum : créer de la prédictibilité (cadence régulière) et limiter le risque (prévenir les dérives). Les Daily Scrums restent toujours à 15 minutes, quelle que soit la durée du Sprint, car ils se répètent chaque jour de travail.

La décision de ne pas déployer l'Increment en production après le Sprint Review remet-elle en cause la valeur de cet Increment selon Scrum ? Quelle distinction Scrum fait-il entre un Increment livrable et un Increment déployé ?

Non, la décision de ne pas déployer en production ne remet pas en cause la valeur ou la validité de l'Increment selon Scrum. Le Scrum Guide distingue clairement deux notions : un Increment doit être 'potentiellement livrable' (potentially releasable), c'est-à-dire qu'il satisfait la Definition of Done et est prêt à être déployé — mais la décision de le déployer effectivement appartient au Product Owner et à l'organisation, pas au cadre Scrum. Le déploiement en production est une décision business, pas une obligation Scrum. Ce qui est essentiel, c'est que l'Increment soit concret, utilisable et qu'il représente une étape concrète vers le Product Goal. La mesure de progrès principale dans Scrum est un Increment fonctionnel satisfaisant la DoD, pas son déploiement en production. Cependant, le gel de déploiement est un signal important pour le Scrum Master : il doit travailler à lever cet obstacle organisationnel et accompagner la direction dans la compréhension que des déploiements fréquents réduisent le risque et maximisent la valeur produit, conformément aux principes lean intégrés dans Scrum.

Comment la contrainte réglementaire d'analyse d'impact imposée par le département conformité s'intègre-t-elle dans le processus Scrum, notamment au niveau du Product Backlog Refinement et de la Definition of Done ?

La contrainte réglementaire est une réalité organisationnelle que Scrum ne peut pas ignorer, mais le Scrum Master ne doit pas 'exempter' l'équipe de cette règle — ce serait irresponsable et potentiellement illégal. En revanche, il existe deux façons de l'intégrer intelligemment dans Scrum. Premièrement, via le Product Backlog Refinement : l'analyse réglementaire peut être intégrée comme une activité de raffinage (refinement) à réaliser en amont, de sorte que seuls les items ayant obtenu leur analyse soient considérés comme 'prêts' (ready) pour être sélectionnés lors du Sprint Planning. Ceci est une pratique de 'Definition of Ready' informelle. Deuxièmement, si l'analyse réglementaire est une condition sine qua non pour livrer, elle peut être intégrée dans la Definition of Done comme critère qualité obligatoire. Le Scrum Master doit travailler avec l'organisation (son rôle de service à l'organisation) pour optimiser ce processus : réduire le délai d'analyse (5 jours est long), impliquer l'équipe conformité plus tôt dans le cycle, et explorer si cette contrainte peut être gérée en parallèle du Sprint plutôt qu'en bloqueur séquentiel. L'objectif est d'éliminer les gaspillages (lean thinking) sans contourner les obligations légales.

Comment le Scrum Master doit-il gérer la présence du directeur de département au Daily Scrum, qui pose des questions et perturbe l'équipe ?

Le Scrum Master doit agir avec Courage pour protéger l'équipe de cette perturbation, qui compromet l'essence même du Daily Scrum. Selon le Scrum Guide, le Daily Scrum est un événement appartenant aux Developers : ce sont eux les participants essentiels. Le Scrum Master et le Product Owner peuvent observer, mais ne sont pas participants actifs. Le directeur, en tant que partie prenante externe, peut tout au plus assister en observateur silencieux — mais poser des questions sur les priorités et la charge de travail des développeurs transforme le Daily Scrum en réunion de statut (status meeting) pour le management, ce qui est explicitement contraire à son but. Le Scrum Master doit d'abord expliquer au directeur, en privé et avec respect, le rôle et le format du Daily Scrum : il est destiné à l'auto-organisation de l'équipe, pas à informer le management. Si le directeur souhaite avoir de la visibilité sur l'avancement, le Scrum Master doit le diriger vers les mécanismes transparents de Scrum : le Product Backlog, le Sprint Backlog, ou la Sprint Review. Le Scrum Master sert l'organisation en l'aidant à comprendre et adopter Scrum — ce cas est une opportunité pédagogique, pas un conflit à éviter.

Quelles sont les conséquences de l'absence de Sprint Goal pour ce Sprint 12, et quel aurait dû être le processus correct lors du Sprint Planning ?

L'absence de Sprint Goal est une violation sérieuse du cadre Scrum avec des conséquences concrètes visibles dans ce cas. Le Sprint Goal est l'objectif unique et cohérent qui donne un sens au Sprint au-delà de la simple liste de tâches. Sans lui : les développeurs manquent de direction commune (ce qui explique le rework causé par des features contradictoires), l'équipe ne peut pas prendre de décisions autonomes sur les priorités en cours de Sprint, et les parties prenantes n'ont pas de vision claire de la valeur attendue. Le Sprint Goal est créé collaborativement par toute la Scrum Team — Product Owner, Scrum Master et Developers — lors du Sprint Planning. Ce n'est pas uniquement la responsabilité du Product Owner. La bonne procédure aurait été : le Product Owner présente les items prioritaires et explique la valeur attendue, puis l'équipe ensemble formule un Sprint Goal qui encapsule l'intention de ce Sprint. La durée du Sprint Planning pour un Sprint de 2 semaines est au maximum de 4 heures — non de 5 heures. Si l'équipe ne parvient pas à définir un Sprint Goal dans le temps imparti, c'est un signal que le Product Backlog n'est pas suffisamment raffiné ou que la communication entre PO et développeurs est déficiente.

Le Product Owner a ajouté des items au Sprint Backlog unilatéralement en cours de Sprint. Est-ce conforme à Scrum ? Qui est propriétaire du Sprint Backlog et quelles sont les règles d'évolution en cours de Sprint ?

Non, ce n'est pas conforme à Scrum. Le Sprint Backlog appartient exclusivement aux Developers. C'est eux qui le créent lors du Sprint Planning et qui le gèrent tout au long du Sprint. Ni le Product Owner, ni le Scrum Master, ni le management ne peuvent y ajouter des items unilatéralement. Le Product Owner peut suggérer des modifications, mais toute adaptation du Sprint Backlog en cours de Sprint se fait en collaboration avec les Developers, et uniquement dans le respect du Sprint Goal. Si le Product Owner souhaite introduire un nouveau besoin urgent, deux scénarios sont possibles : soit le besoin peut être intégré sans compromettre le Sprint Goal (les Developers peuvent accepter un échange d'items), soit le besoin est suffisamment important pour remettre en question le Sprint Goal, auquel cas le Product Owner peut annuler le Sprint (seule personne habilitée à le faire). Ajouter des items unilatéralement compromet la capacité de l'équipe à atteindre le Sprint Goal, nuit à la prévisibilité du Sprint, et viole le principe d'auto-gestion (self-managing) de l'équipe. Le Scrum Master doit intervenir, expliquer cette règle au Product Owner et rétablir l'intégrité du Sprint Backlog.

L'amélioration technique identifiée lors de la Sprint Retrospective précédente n'a pas été priorisée ni ajoutée au Product Backlog. Quel mécanisme Scrum aurait dû être appliqué, et quel rôle le Scrum Master joue-t-il dans ce contexte ?

La Sprint Retrospective doit aboutir à des améliorations concrètes et actionnables, planifiées pour être implémentées dès le Sprint suivant — c'est son objectif principal. Ne pas donner suite aux améliorations identifiées revient à annuler la valeur de cet événement et viole le pilier d'Adaptation de l'empirisme Scrum. Pour une amélioration technique comme la refactorisation d'un module critique, le processus correct est le suivant : à l'issue de la rétrospective, l'équipe sélectionne les améliorations les plus impactantes et les transforme en items concrets, qui peuvent être ajoutés au Product Backlog (avec l'accord du Product Owner pour la priorisation) ou directement planifiés dans le Sprint Backlog suivant en tant que tâches d'amélioration. Le Product Owner doit comprendre la valeur de ces améliorations techniques (qualité, réduction de la dette technique, durabilité du produit) pour les prioriser correctement. Le rôle du Scrum Master est central ici : il facilite la rétrospective pour qu'elle produise des engagements concrets, s'assure du suivi lors de la rétrospective suivante, et coach le Product Owner sur l'importance d'intégrer la qualité technique dans le Product Backlog. Si le Product Owner refuse systématiquement de prioriser des améliorations techniques, le Scrum Master doit avoir le Courage de lui expliquer les risques à long terme pour la valeur produit.