Cas pratiques Agile/Scrum

Contexte : Lors du dernier sprint, un bug critique en production a causé 4 heures d'interruption de service. Deux développeurs se rejettent mutuellement la responsabilité. L'ambiance dans l'équipe est tendue et la rétrospective est prévue demain. Le Problème : Si la rétrospective n'est pas bien animée, elle risque de dégénérer en session de reproches au lieu de produire des améliorations constructives. Contraintes : Choisir et justifier un format de rétrospective adapté à la situation (Start/Stop/Continue, 4Ls, Sailboat, etc.). Définir les règles d'animation pour maintenir un cadre bienveillant. Prévoir comment traiter le sujet du bug sans désigner de coupable. Proposer des actions concrètes issues de la session. Livrable attendu : Un plan d'animation de la rétrospective avec le format choisi, les règles de fonctionnement et les actions d'amélioration attendues.

Contexte : Une équipe Scrum de 7 personnes travaille en remote avec des membres en France, au Maroc et en Tunisie. L'équipe livre régulièrement des fonctionnalités qui passent en production mais nécessitent des corrections dans les 48h suivantes. Le Problème : Il n'existe pas de Definition of Done formelle. Chaque développeur a sa propre interprétation de ce que signifie « terminé ». Contraintes : Proposer une Definition of Done adaptée au contexte distribué. Inclure les critères de qualité (tests, documentation, code review). Définir comment valider la DoD pour chaque story. Prévoir un processus de mise à jour de la DoD en rétrospective. Livrable attendu : Une Definition of Done complète et opérationnelle avec les critères par catégorie et le processus de validation proposé.

Contexte : Une équipe de 5 développeurs travaille en Scrum depuis 6 mois. Sur les 10 derniers sprints, elle n'a terminé son sprint goal que 2 fois. À chaque fin de sprint, 30 à 40% des user stories sont reportées au sprint suivant. Le Problème : L'équipe est démotivée et le management commence à douter de l'Agile. Le Scrum Master doit identifier les causes racines et proposer des améliorations concrètes. Contraintes : Analyser les causes possibles via une rétrospective structurée. Identifier si le problème vient de la vélocité, de l'estimation, des interruptions ou du scope. Proposer 3 actions correctives concrètes et mesurables. Définir comment mesurer l'amélioration sur les 3 prochains sprints. Livrable attendu : Une analyse des causes racines et un plan d'amélioration avec des indicateurs de suivi précis.

Contexte : Une équipe Scrum de 6 personnes doit estimer un nouveau projet de refonte d'un portail client. Le projet contient 25 user stories identifiées lors d'ateliers de cadrage. C'est la première fois que l'équipe estime un projet de cette taille avec Planning Poker. Le Problème : Les estimations varient énormément entre les développeurs (certains donnent 2 points, d'autres 13 pour la même story) et les sessions durent trop longtemps. Contraintes : Expliquer la séquence de Fibonacci et son utilisation en Planning Poker. Définir une user story de référence (story de calibrage). Proposer une technique pour réduire les écarts d'estimation. Calculer la vélocité prévisionnelle et la durée estimée du projet. Livrable attendu : Un guide de session Planning Poker avec la story de référence, la méthode de consensus et une estimation de la durée totale du projet en sprints.

Contexte : Un chef de projet rejoint une équipe Scrum existante. Le Product Backlog contient 80 user stories sans priorité, sans estimation et avec des descriptions incomplètes. Le prochain sprint commence dans 3 jours. Le Problème : L'équipe ne sait pas par où commencer et le Product Owner n'est disponible que 2 heures par semaine. Contraintes : Proposer une méthode de priorisation adaptée (MoSCoW, Valeur/Effort ou Kano). Identifier les user stories nécessitant une clarification avant d'être estimées. Organiser une session de Backlog Refinement efficace en 2 heures. Sélectionner les stories à inclure dans le sprint suivant. Livrable attendu : Une approche structurée de Backlog Refinement avec la méthode de priorisation choisie et justifiée, et les critères de sélection pour le sprint.

Contexte : Deux équipes Scrum travaillent sur le même produit : Team Alpha développe le frontend, Team Beta développe l'API backend. Team Alpha a besoin d'un endpoint API que Team Beta n'a pas encore développé. Ce blocage dure depuis 2 sprints et impacte la vélocité d'Alpha. Le Problème : Les deux équipes ont des backlogs et des priorités indépendants. Il n'existe pas de mécanisme de synchronisation entre elles. Contraintes : Identifier les bonnes pratiques de coordination inter-équipes (Scrum of Scrums, PI Planning, contrat d'interface). Proposer une solution à court terme pour débloquer Team Alpha. Définir un processus pour anticiper ce type de dépendance à l'avenir. Clarifier les responsabilités de chaque Scrum Master dans ce cas. Livrable attendu : Un plan de résolution immédiate du blocage et un processus de coordination inter-équipes pour prévenir les dépendances futures.

Contexte : L'équipe est au 5e jour d'un sprint de 10 jours. Le directeur commercial arrive avec une demande urgente d'un client stratégique : ajouter une fonctionnalité d'export Excel d'ici la fin de la semaine. L'équipe a déjà consommé 60% de sa capacité. Le Problème : Comment gérer cette interruption sans violer les règles Scrum, sans frustrer le commercial, et sans démoraliser l'équipe ? Contraintes : Évaluer l'impact sur le sprint goal en cours. Appliquer les bonnes pratiques Scrum pour gérer les changements en cours de sprint. Proposer les options possibles au Product Owner et au management. Documenter la décision prise et son impact sur la vélocité. Livrable attendu : Une analyse de situation avec les options proposées, la décision recommandée et la communication à faire auprès des parties prenantes.

Contexte : Une startup de 8 personnes vient de recruter son premier Scrum Master. L'équipe n'a jamais travaillé en Agile et livre ses projets en mode cascade avec des réunions de planning de 2 jours tous les 3 mois. Le Problème : Le premier sprint doit démarrer dans 2 semaines. Le Product Owner a une liste de 60 tâches non priorisées et l'équipe ne sait pas comment estimer, prioriser ou organiser les cérémonies. Contraintes : Organiser le Product Backlog avec les informations disponibles. Définir la durée du sprint (1 ou 2 semaines) et justifier. Planifier les cérémonies Scrum (Planning, Daily, Review, Rétrospective) avec durée et participants. Expliquer à l'équipe comment estimer en Story Points. Livrable attendu : Un plan de lancement du premier sprint incluant la structure du backlog, le calendrier des cérémonies, et les critères de Definition of Done proposés.

Contexte : Une équipe support de 4 personnes gère des tickets clients, des correctifs urgents et des petites évolutions. Elle n'a pas de processus formalisé : les tâches arrivent par email, Slack et téléphone, et certaines restent en attente plusieurs semaines sans visibilité. Le Problème : L'équipe veut adopter une méthode Agile légère sans les contraintes d'un Scrum complet (sprints fixes, cérémonies lourdes). Contraintes : Concevoir un tableau Kanban adapté avec les colonnes pertinentes. Définir les WIP limits (Work In Progress) pour chaque colonne. Établir les règles de priorisation (SLA par type de ticket). Proposer un processus de review hebdomadaire simple. Livrable attendu : La structure du tableau Kanban avec les WIP limits justifiées, les règles de flux et le processus d'amélioration continue proposé.

Contexte : L'équipe Scrum a terminé son 4e sprint sur un projet de refonte du système de facturation. Les fonctionnalités livrées sont techniques (optimisation des requêtes SQL, refactoring de modules, mise en place de tests unitaires). La Sprint Review est prévue avec le DG, le DAF et le responsable commercial — aucun n'est technique. Le Problème : Les sprints précédents, les stakeholders étaient déconnectés et repartaient sans comprendre la valeur livrée ni donner de feedback utile. Contraintes : Adapter la présentation pour un public non technique. Traduire les livrables techniques en valeur métier concrète. Préparer des questions pour stimuler le feedback. Gérer les questions sur les délais et le budget. Livrable attendu : Un plan de Sprint Review adapté aux stakeholders non techniques, avec les messages clés, la démonstration prévue et les questions de feedback.