La direction technique a imposé trois Product Backlogs distincts pour les trois équipes Scrum. Est-ce conforme au cadre Scrum ? Que doit faire Anna ?

Cette structure est non conforme au cadre Scrum. Le Scrum Guide stipule explicitement qu'il ne doit exister qu'un seul Product Backlog par produit, même si plusieurs équipes Scrum travaillent sur ce même produit. Un Product Backlog unique garantit une source de vérité commune, évite les duplications et les contradictions de priorités, et permet au Product Owner de disposer d'une vision cohérente de la valeur à délivrer. Anna doit donc consolider les trois backlogs en un seul Product Backlog unifié dont elle assume la responsabilité de l'ordonnancement. Elle peut déléguer certaines activités de raffinement à des membres des équipes, mais elle reste seule accountable pour l'ordre et la transparence du backlog. Cette consolidation résoudra directement les 14 items dupliqués identifiés.

La direction demande à Anna de fournir chaque semaine un rapport de vélocité consolidé pour mesurer la 'valeur produit' générée. Anna doit-elle accepter ce mode de reporting ?

Anna doit refuser ce mode de reporting et proposer une alternative alignée avec les principes Scrum et le cadre EBM (Evidence-Based Management). La vélocité est une métrique de capacité d'équipe — elle mesure la quantité de travail réalisé par Sprint — et non la valeur produit. Une vélocité de 87 points ne dit rien sur l'impact réel pour les utilisateurs ou le business. Anna devrait plutôt proposer des indicateurs d'outcomes tels que : le taux de conversion des visiteurs en acheteurs, le taux de rétention des clients, le revenu moyen par session, ou le taux d'adoption des nouvelles fonctionnalités. Ces métriques mesurent ce que le produit accomplit réellement pour ses utilisateurs, conformément à la responsabilité première du Product Owner : maximiser la valeur du produit.

Lors du Sprint Planning, un développeur senior de l'équipe catalogue demande à Anna de valider son estimation de 13 points pour un item de recherche avancée, arguant qu'elle a plus d'expérience produit. Anna doit-elle approuver ou modifier cette estimation ?

Anna ne doit ni approuver ni modifier l'estimation. Dans le cadre Scrum, les estimations appartiennent exclusivement aux Développeurs : ils sont seuls compétents pour évaluer l'effort technique requis pour réaliser un item. Le Product Owner définit le 'quoi' et le 'pourquoi' — il présente les items, clarifie les critères d'acceptation et exprime la valeur métier — mais il n'a aucune autorité sur le 'comment', qui inclut les estimations. Valider ou rejeter une estimation reviendrait à violer l'auto-organisation des Développeurs et pourrait fausser la capacité réelle de l'équipe. Anna peut en revanche clarifier le besoin métier derrière l'item si l'équipe manque d'informations pour estimer, ou vérifier que la Definition of Done est bien prise en compte dans l'estimation.

Sophie peut-elle annuler le Sprint en cours ? Si oui, dans quelles conditions et selon quelle autorité ?

Oui, Sophie peut et devrait vraisemblablement annuler ce Sprint. Dans le cadre Scrum, seul le Product Owner détient l'autorité d'annuler un Sprint, et cette décision se justifie précisément lorsque le Sprint Goal devient obsolète — ce qui est le cas ici : la décision réglementaire rend sans objet le module de synchronisation cloud qui était au cœur du Sprint Goal. Avec 6 items sur 9 directement impactés, la poursuite du Sprint produirait des livrables inutilisables ou non conformes, ce qui représenterait un gaspillage majeur. Lors de l'annulation, les items complétés et conformes à la Definition of Done sont acceptés, les items non terminés retournent dans le Product Backlog. Sophie devra ensuite immédiatement re-ordonner le backlog pour intégrer les nouvelles exigences réglementaires et définir un nouveau Sprint Goal aligné sur la conformité RGPD lors du prochain Sprint Planning.

Le directeur médical a contacté directement les développeurs pour leur imposer des modifications techniques. Est-ce conforme à Scrum ? Quel est le rôle de Sophie dans cette situation ?

Cette démarche n'est pas conforme au cadre Scrum. Les parties prenantes externes, y compris le directeur médical, ne peuvent pas adresser directement des instructions techniques aux développeurs ni modifier le Sprint Backlog. Le Sprint Backlog appartient aux développeurs, et toute modification du périmètre passe par le Product Owner. Sophie est la seule interface légitime entre les parties prenantes et l'équipe pour les décisions de priorisation et de périmètre. Elle doit donc : (1) recevoir les exigences du directeur médical et les qualifier en items Product Backlog, (2) décider si le Sprint doit être annulé au vu de l'obsolescence du Sprint Goal, (3) re-ordonner le backlog pour placer les items de conformité RGPD en tête de priorité. Quant à la solution technique de chiffrement, elle reste de la responsabilité des développeurs qui décident du 'comment', pas du directeur médical ni de Sophie.

Comment Sophie doit-elle mesurer si la mise en conformité RGPD délivrée au Sprint suivant apporte réellement de la valeur, au-delà de la simple livraison du module de chiffrement ?

Sophie doit distinguer output et outcome. Livrer un module de chiffrement est un output — une fonctionnalité produite. La valeur réelle (outcome) se mesure par l'impact concret sur les utilisateurs et le business. Dans ce contexte, Sophie pourrait suivre des indicateurs tels que : le taux de rétention des patients après mise en conformité (les utilisateurs restent-ils sur l'application une fois les nouvelles exigences implémentées ?), le nombre de patients actifs quotidiens, le taux d'adoption du module de synchronisation cloud sécurisé, ou encore l'absence d'incidents de sécurité signalés. Ces métriques s'inscrivent dans le cadre EBM et permettent de valider que la conformité réglementaire n'a pas dégradé l'expérience utilisateur, tout en progressant vers le Product Goal de 10 000 patients autonomes. La vélocité du Sprint ne serait pas un indicateur pertinent de cette valeur.

Comment Théo devrait-il gérer les demandes contradictoires des trois clients lors du Sprint Review et la pression du directeur commercial pour tout intégrer dans le prochain Sprint ?

Théo doit affirmer son rôle de Product Owner comme seule personne responsable de l'ordonnancement du Product Backlog. Le Scrum Guide stipule que le Product Owner est une personne unique — pas un comité — précisément pour éviter les décisions par consensus paralysant. Face aux demandes contradictoires, Théo doit : (1) écouter et collecter toutes les demandes des parties prenantes lors du Sprint Review, qui est justement l'événement dédié à cet échange, (2) intégrer ces demandes comme items dans le Product Backlog, (3) les prioriser selon la valeur business, le risque et l'alignement avec le Product Goal — pas selon la pression politique ou la récence de la demande. Il peut expliquer au directeur commercial que toutes les demandes ne peuvent pas être dans le prochain Sprint car les développeurs décident eux-mêmes du nombre d'items sélectionnables selon leur capacité. Le Sprint Goal du prochain Sprint doit refléter la priorité maximale, pas une somme de compromis.

L'absence de Product Goal formalisé depuis 4 Sprints a-t-elle un impact sur l'efficacité de l'équipe ? Que doit faire Théo pour remédier à cette situation ?

L'absence de Product Goal est un problème structurel majeur. Selon le Scrum Guide 2020, le Product Goal est l'engagement du Product Backlog : il décrit l'état futur du produit et sert d'objectif à long terme pour toute l'équipe Scrum. Sans Product Goal, l'équipe travaille sans cap stratégique, ce qui explique les difficultés des développeurs à comprendre la finalité de leur travail et la dispersion constatée des Sprints. Chaque Sprint doit progresser vers le Product Goal — sans lui, les Sprint Goals eux-mêmes perdent leur cohérence. Théo doit donc définir un Product Goal clair, mesurable et temporellement situé (ex. : 'atteindre 500 PME actives utilisant le module de gestion de ressources d'ici Q3'), co-construire cette vision avec les parties prenantes clés, puis re-ordonner le Product Backlog en cohérence avec ce Goal. Les demandes clients doivent être filtrées à l'aune de ce Product Goal, et non traitées de façon réactive.

Théo assiste à tous les Daily Scrums sur demande de son directeur. Est-ce conforme à Scrum ? Quel impact cela peut-il avoir sur l'équipe ?

La présence de Théo au Daily Scrum n'est pas requise par Scrum et peut devenir contre-productive. Le Daily Scrum est un événement appartenant aux développeurs, organisé par et pour eux afin de synchroniser leur travail et planifier les 24 prochaines heures. Le Product Owner peut y assister, mais sa présence n'est pas obligatoire. En assistant systématiquement au Daily Scrum sur injonction hiérarchique, Théo risque d'influencer involontairement les échanges, de brider la liberté des développeurs à s'auto-organiser, et de transformer l'événement en reporting vers le PO plutôt qu'en outil de coordination interne. De plus, le Daily Scrum n'est pas un outil de reporting managérial — la transparence pour le management doit passer par les artefacts Scrum (Product Backlog, Sprint Backlog, Increment). Théo devrait clarifier avec son directeur que la transparence sur l'avancement est assurée par ces artefacts et les événements Scrum dédiés, et que sa présence quotidienne obligatoire n'est pas justifiée par le cadre Scrum.

Les deux équipes ont des Definitions of Done différentes, dont l'une non conforme aux exigences réglementaires. Comment cette situation doit-elle être résolue selon le cadre Scrum ?

La situation révèle un déficit de gouvernance de la Definition of Done. Selon Scrum, la DoD est l'engagement de l'Increment : chaque Increment livré doit la respecter pour être considéré comme potentiellement publiable. Lorsqu'une organisation ou plusieurs équipes travaillent sur le même produit, la DoD doit être au minimum conforme aux standards organisationnels — ici les exigences réglementaires de la Banque de France constituent un standard organisationnel non négociable. La résolution passe par : (1) la définition d'une DoD commune minimale pour les deux équipes, intégrant les tests de sécurité et de pénétration requis, (2) chaque équipe pouvant adopter une DoD plus stricte que ce minimum commun mais pas moins exigeante. Les Développeurs sont responsables de la création et du respect de la DoD, mais la DoD peut et doit intégrer les standards organisationnels. L'Increment de l'équipe 'UX & Onboarding' ne peut pas être considéré comme 'Done' tant qu'il ne satisfait pas cette DoD harmonisée, et les items non conformes doivent retourner dans le Product Backlog.

Le CTO demande à Lucie un plan de release détaillé avec un périmètre figé sur 10 semaines. Scrum mandate-t-il un tel plan ? Comment Lucie doit-elle répondre ?

Scrum ne mandate pas de plan de release détaillé à périmètre figé. Le Scrum Guide définit uniquement trois artefacts (Product Backlog, Sprint Backlog, Increment) et ne prescrit pas de release plan formel. La décision de release est une décision business appartenant au Product Owner, prise en collaboration avec l'organisation, et peut intervenir à tout moment dès qu'un Increment satisfait la Definition of Done. Lucie peut répondre positivement à l'objectif de date (10 semaines) sans s'engager sur un périmètre figé. Elle peut proposer : (1) un Product Goal clair pour la release, définissant les critères de valeur attendus, (2) une liste ordonnée des items Product Backlog prioritaires à traiter sur les 5 prochains Sprints, avec la transparence sur les incertitudes, (3) une communication sur le fait que le périmètre exact sera affiné Sprint par Sprint selon les apprentissages. Cette approche préserve l'empirisme de Scrum tout en répondant aux besoins légitimes de planification du CTO. Le périmètre peut évoluer tant que le Sprint Goal de chaque Sprint est respecté.

Lucie envisage de déléguer entièrement la gestion du Product Backlog à un Business Analyst de chaque équipe pour gagner du temps. Quelles sont les implications de cette décision selon Scrum ?

La délégation est possible mais doit être encadrée avec précision. Selon le Scrum Guide, le Product Owner peut déléguer des activités de gestion du Product Backlog (rédaction d'items, raffinement, clarification) à d'autres membres de l'équipe ou à des parties prenantes, mais il reste seul accountable de l'ordonnancement et de la maximisation de la valeur. La notion de 'Business Analyst' n'est pas un rôle Scrum — Scrum définit uniquement trois rôles : Product Owner, Scrum Master et Developers. Des individus peuvent avoir cette expertise, mais ils ne forment pas un rôle Scrum à part entière. En pratique, Lucie peut déléguer la rédaction et le raffinement d'items aux développeurs et experts métier, mais elle ne peut pas déléguer la responsabilité de l'ordre du backlog ni sa transparence. Le risque d'une délégation totale est la perte de cohérence stratégique : sans implication active de Lucie, les items pourraient ne plus être alignés avec le Product Goal et les priorités business, compromettant la valeur délivrée sprint après sprint.

Nadia peut-elle imposer aux développeurs un objectif de vélocité de 42 points et alléger la Definition of Done pour atteindre cet objectif ? Quelles seraient les conséquences ?

Nadia ne peut ni imposer un objectif de vélocité ni modifier unilatéralement la Definition of Done. Concernant la vélocité : les développeurs sont seuls responsables de la sélection des items lors du Sprint Planning, selon leur capacité réelle et leur estimation propre. Le Product Owner ne peut pas approuver ni forcer des estimations. La vélocité est un outil de planification — une métrique descriptive de capacité — et non un objectif de performance imposable. Demander 42 points alors que la capacité moyenne est de 30 points risque de générer une dette technique, des Increments non conformes à la DoD, et une dégradation de la qualité. Concernant la DoD : elle représente l'engagement de qualité de l'Increment. Supprimer les tests d'accessibilité reviendrait à produire des Increments non conformes aux standards de qualité et potentiellement illégaux (réglementations RGAA/WCAG). Une DoD affaiblie ne génère pas de gain de vélocité réel — elle transfère le coût vers des dettes techniques futures. Farida a raison de s'opposer. Nadia devrait plutôt retravailler les priorités du Product Backlog pour maximiser la valeur livrable dans les 6 Sprints restants.

Nadia a dirigé et imposé un ordre du jour à la Sprint Retrospective. Est-ce conforme au rôle du Product Owner dans cet événement ?

Non, le comportement de Nadia est non conforme au cadre Scrum. La Sprint Retrospective est un événement appartenant à l'équipe Scrum dans son ensemble, facilité par le Scrum Master, et non dirigé par le Product Owner. Son objectif est d'inspecter le fonctionnement de l'équipe (processus, outils, relations, pratiques) afin d'identifier des améliorations — pas d'analyser les fonctionnalités livrées (cela relève du Sprint Review). En imposant un ordre du jour centré sur la productivité fonctionnelle, Nadia a détourné la Retrospective de sa finalité et a empêché l'équipe d'aborder des problèmes interpersonnels réels qui freinent probablement la collaboration et donc indirectement la vélocité. Le Scrum Master, Farida, est accountable de la facilitation de cet événement et de l'efficacité de l'équipe Scrum. Nadia peut participer à la Retrospective et exprimer ses observations, mais elle ne doit pas en contrôler le contenu ni l'agenda.

Nadia n'a invité que le directeur général au Sprint Review, excluant les responsables des associations partenaires. Quelles sont les implications de cette décision pour la valeur produit ?

Cette décision est une erreur de gouvernance du Product Owner. Selon Scrum, c'est le Product Owner qui est responsable d'inviter les parties prenantes pertinentes au Sprint Review. Cet événement est précisément conçu pour inspecter l'Increment et adapter le Product Backlog grâce aux feedbacks des parties prenantes. En excluant les responsables des associations partenaires — qui sont les utilisateurs principaux de la plateforme — Nadia prive l'équipe du feedback le plus précieux : celui des personnes qui utilisent réellement le produit. Le Sprint Review n'est pas un rapport de statut pour la hiérarchie, mais une session de travail collaborative visant à valider la valeur délivrée et à affiner les priorités. La conséquence directe est un Product Backlog mal adapté aux vrais besoins utilisateurs, des Sprint Goals potentiellement déconnectés de la réalité terrain, et une mesure de valeur faussée. Nadia devrait systématiquement inviter les représentants des associations partenaires et mesurer la valeur via des indicateurs d'usage réels (taux de mise en relation réussies, taux d'adoption par les bénévoles, etc.) plutôt que via la seule satisfaction du directeur général.