La réunion des Three Amigos : maximiser la clarté et la qualité avant le Sprint

Cet article fait partie de la série Les cérémonies Scrum.
Dans de nombreuses équipes agiles, la préparation des fonctionnalités ressemble parfois à un jeu du téléphone arabe : le Product Owner émet une idée, les développeurs tentent de la traduire en code, et les ingénieurs qualité découvrent tardivement que le résultat ne correspond pas aux attentes. Pour briser ce fonctionnement en silo, une pratique collaborative s’est imposée : la réunion des Three Amigos (ou « les trois amis »). Avant d’entrer dans le détail, levons toute ambiguïté : cette session n’est pas un événement officiel prescrit par le Scrum Guide officiel de Jeff Sutherland et Ken Schwaber. Il s’agit d’une pratique complémentaire issue du Behavior-Driven Development (BDD) et de la Spécification par l’exemple, formalisée notamment par des figures comme George Dinwiddie et Gojko Adzic, et ancrée historiquement dans l’Extreme Programming (XP). Adoptée par une multitude d’équipes pratiquant le framework Scrum, elle permet de maximiser la clarté avant le lancement des développements.

Les trois perspectives : Alignement indispensable du Métier, du Dev et du Test

L’objectif central de la réunion des Three Amigos est de confronter trois regards indispensables sur une User Story avant d’écrire la moindre ligne de code. Plutôt que de laisser chaque rôle travailler de manière séquentielle, l’échange réunit simultanément :

• La perspective Métier (Product Owner / Business Analyst) : Elle apporte la vision fonctionnelle, le « Pourquoi » et la valeur attendue par les utilisateurs ou l’entreprise.
• La perspective Développement (Développeur) : Elle évalue la faisabilité technique, le « Comment », les contraintes d’architecture et l’effort d’implémentation.
• La perspective Qualité (Testeur / QA) : Elle pose les questions qui dérangent, le « Et si… ? », identifie les scénarios d’erreur et définit les critères de validation finale.

Grâce à ce dialogue à trois voix, l’équipe clarifie les besoins réels, lève les zones d’ombre et s’accorde sur des règles métier précises. Cette démarche préventive réduit drastiquement les allers-retours en cours de Sprint, limite les rejets en phase de recette et élimine une grande partie des bugs de compréhension.

Format Gherkin, outils BDD et timing dans le cycle Scrum

Pour consigner le résultat de ces échanges, les équipes s’appuient très souvent sur le langage Gherkin et sa structure naturelle Given / When / Then (Étant donné / Lorsque / Alors). Ce format compréhensible aussi bien par les profils business que par la technique permet de formuler des scénarios d’acceptation sans ambiguïté. Des frameworks de test comme Cucumber permettent ensuite de transformer ces spécifications directement en tests automatisés exécutables.

Dans le calendrier d’une équipe Scrum, la session des Three Amigos intervient généralement pendant ou juste après l’affinement du Product Backlog (Backlog Refinement), et impérativement avant le Sprint Planning. Une fois formalisées, ces spécifications enrichissent les tickets dans vos logiciels de suivi comme Jira, Trello ou Azure DevOps. Pour le partage documentaire ou les ateliers visuels, les équipes utilisent fréquemment Confluence ou Miro.

Exemple concret : De la User Story floue à la spécification vivante

Rien ne vaut un exemple concret pour saisir la valeur ajoutée d’une réunion Three Amigos sur la qualité d’une User Story.

Avant la session Three Amigos

La User Story rédigée par le Product Owner est très sommaire :

« En tant que client, je veux appliquer un code de réduction lors de ma commande afin de bénéficier d’une remise sur mon panier. »
Critères d’acceptation initiaux : Le code promo doit s’appliquer et recalculer le montant total.

Cette description soulève immédiatement de multiples questions : Que se passe-t-il si le code est périmé ? Peut-on cumuler deux codes ? Y a-t-il un montant minimum d’achat ?

Après la session Three Amigos

À la suite d’un échange de 15 minutes entre le Product Owner, un développeur et une testeuse, la story s’enrichit de règles métiers tranchées et de scénarios en format Gherkin :

Scénario 1 : Application d’un code valide
Étant donné que mon panier contient un total de 100 € d’articles
Lorsque je saisis le code de réduction « SUMMER20 »
Alors une remise de 20 € est appliquée et le montant net à payer passe à 80 €.

Scénario 2 : Saisie d’un code expiré
Étant donné que le code promo « WINTER10 » a expiré le 31 décembre
Lorsque je saisis ce code lors de la validation du panier
Alors le message d’erreur « Ce code promo n’est plus valide » apparaît et aucun rabais n’est appliqué.

Scénario 3 : Tentative de cumul de codes non autorisée
Étant donné qu’un premier code promo « SUMMER20 » est déjà actif sur mon panier
Lorsque je tente d’ajouter un second code « BIENVENUE5 »
Alors le système bloque la demande avec le message « Les offres promotionnelles ne sont pas cumulables ».

Erreurs fréquentes et pièges à éviter

Bien que très efficace, la réunion des Three Amigos peut perdre son utilité si l’équipe tombe dans certains pièges classiques :

• Dériver vers une réunion de spécification technique : L’objectif est de s’accorder sur le comportement métier attendu, non de décider du découpage des classes ou du schéma de base de données. Gardez le cap sur le besoin fonctionnel.
• Travailler en l’absence d’un des trois profils : Réaliser la session sans le testeur ou sans le développeur détruit tout l’intérêt du rituel. L’absence d’un regard affaiblit immédiatement la détection des failles.
• Organiser des réunions trop longues et épuisantes : Faire siéger toute l’équipe pendant deux heures pour passer en revue 15 stories est contre-productif. Préférez des sessions courtes et ciblées menées par un sous-groupe restreint.

Conseils pratiques pour réussir vos réunions Three Amigos

Voici quelques bonnes pratiques à mettre en place pour rendre vos sessions digestes et performantes :

1. Time-boxer la séance : Accordez-vous 15 à 30 minutes maximum par User Story. Si le débat s’éternise, la story est sûrement trop vaste ou insuffisamment mûre et doit être retravaillée.
2. Préparer des exemples en amont : Demandez au Product Owner et au testeur d’arriver avec quelques cas concrets en tête avant de démarrer l’atelier.
3. Cibler les User Stories prioritaires ou complexes : Ne passez pas nécessairement 100 % de votre backlog au tamis des Three Amigos. Donnez la priorité aux histoires présentant un risque métier important ou une ambiguïté forte.
4. Faire tourner les participants : Variez les développeurs et les testeurs présents aux sessions pour diffuser la compréhension globale du produit et renforcer la cohésion d’équipe.

Pour aller plus loin

Pour approfondir la démarche BDD et l’art d’illustrer les besoins par l’exemple, nous vous conseillons vivement la lecture de deux ouvrages de référence : Specification by Example de Gojko Adzic, qui décortique les meilleures pratiques d’équipes agiles performantes, ainsi que BDD in Action de John Ferguson Smart, une bible indispensable pour mettre en œuvre le BDD de bout en bout.

En conclusion, bien que la réunion des Three Amigos ne figure pas au rang des événements officiels du Scrum Guide, elle s’avère être un levier formidable pour aligner l’ensemble des acteurs du projet. En clarifiant le besoin avant le codage, vous transformez vos exigences passives en spécifications vivantes et prêtes à être développées sereinement.

Et dans votre équipe, comment assurez-vous l’alignement entre le Métier, le Développement et la Qualité avant un Sprint ? Avez-vous déjà testé le format des Three Amigos ou la syntaxe Gherkin ? Venez partager vos retours d’expérience en commentaire !

Photo : Antoni Shkraba sur Pexels.

Pour aller plus loin

Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.

Sources

• Le Guide Scrum officiel (Scrum Guide)
• Agile Alliance – What are the Three Amigos in Agile?
• George Dinwiddie’s Blog – Three Amigos
• Cucumber Documentation – Gherkin Syntax

Sur le même sujet

• Le Sprint Planning
• La Mêlée quotidienne (Daily Scrum) : le guide complet pour dynamiser votre synchronisation d’équipe
• La Sprint Review (Revue de Sprint) dans Scrum : bien plus qu’une simple démonstration produit
• La Retro En Agilité
• L’affinement du Product Backlog : la fausse 5e cérémonie Scrum indispensable
• Le Scrum of Scrums : Coordonner plusieurs équipes Scrum en agilité à l’échelle
• Glossaire Scrum : tous les termes de l’agilité expliqués
• Toutes les cérémonies Scrum