Dans une équipe Scrum ou Kanban, le BA agile travaille au plus près du backlog. Il découpe les epics en stories, anime l'affinage et les séances à trois avec un développeur et un testeur, transforme les règles métier en exemples concrets puis en scénarios Gherkin, construit la story map d'un nouveau parcours. Les offres françaises le présentent souvent en binôme avec le product owner, parfois sous le titre « PO / business analyst », et dans des trains SAFe.
La frontière avec le product owner pose la première question à l'entretien. Un BA qui prend les décisions de priorité crée un deuxième PO. Un BA qui recopie dans Jira ce que le PO lui dicte n'apporte rien à l'équipe. Le second écueil touche les profils formés au cycle en V. Ils écrivent de bonnes spécifications détaillées et découpent leurs stories par couche technique, base, API puis écran.
Pendant l'entretien, le candidat découpe une story trop grosse, illustre une règle métier par des exemples chiffrés, puis écrit deux scénarios Gherkin. Le PDF ajoute un cas de 20 minutes sur l'ajout du paiement en plusieurs fois dans un parcours de commande.
Pratiques et outils d'un BA en squad
User stories et critères INVEST
La story décrit un besoin d'utilisateur et sa valeur, avec des critères d'acceptation. Les critères INVEST (indépendante, négociable, porteuse de valeur, estimable, petite, testable) servent de contrôle avant l'entrée en sprint. Le BA est jugé sur sa capacité à découper verticalement, chaque tranche livrant un morceau utilisable.
Spécification par l'exemple et example mapping
La spécification par l'exemple remplace les phrases abstraites par des cas chiffrés que tout le monde comprend. L'example mapping, proposé par l'équipe Cucumber, organise une courte séance avec des cartes de couleur : la story, ses règles, un ou plusieurs exemples par règle et les questions restées ouvertes.
Gherkin
Le langage des scénarios BDD : Feature, Rule, Scenario, Given, When, Then, Background, Scenario Outline et Examples. Il existe en français (Fonctionnalité, Étant donné, Quand, Alors). Un bon scénario décrit un comportement métier en quelques lignes, sans clic ni nom de champ technique.
Cucumber et outils BDD
Cucumber exécute les scénarios Gherkin en les reliant à du code de test écrit par les développeurs ou les automaticiens. Des équivalents existent dans d'autres langages, comme Reqnroll en .NET. Le BA n'écrit pas ce code, mais il rédige ou relit les scénarios et sait lire un rapport d'exécution.
Story mapping
Une carte du parcours utilisateur : les activités dans l'ordre en haut, les stories en dessous, de la plus nécessaire à la plus accessoire. Des lignes horizontales délimitent les versions successives. Elle sert à définir une première version qui couvre tout le parcours, même de façon minimale.
Impact mapping
Une carte qui part d'un objectif mesurable, liste les acteurs dont le comportement doit changer, les impacts attendus puis les livrables possibles. Elle aide à relier le backlog à un objectif et à écarter les demandes qui n'y contribuent pas.
Jira, Confluence et Xray
Jira porte le backlog et les stories, Confluence les règles métier transverses et les décisions, Xray relie les scénarios Cucumber aux stories et suit leurs exécutions. Sans outil de test, des étiquettes reliant chaque scénario à sa story suffisent à garder une traçabilité.
IIBA-AAC
L'Agile Analysis Certification de l'IIBA s'appuie sur l'Agile Extension to the BABOK Guide, version 2, rédigée avec l'Agile Alliance. L'examen compte 85 questions en deux heures, surtout des mises en situation, passées en ligne sous surveillance.
Le BA agile intervient dans une squad, aux côtés d'un product owner qui garde la priorisation et l'acceptation des stories. Dans les grandes organisations, un BA suit parfois deux équipes ou travaille au niveau d'un train SAFe, sur les features et leurs critères d'acceptation avant la planification. Chez un éditeur, le rôle se confond souvent avec celui de product owner. En mission pour une ESN, le BA arrive dans une squad déjà lancée et doit reprendre un backlog existant. La pratique du BDD varie beaucoup d'une équipe à l'autre : reste à savoir si les scénarios sont automatisés ou seulement écrits.
Points attendus d'un business analyst agile
- Affinage du backlog et découpage vertical
- Spécification par l'exemple et Gherkin
- Story mapping et impact mapping
- Critères d'acceptation, définition de terminé et non fonctionnel
- Documentation vivante et travail avec l'automatisation
- Partage des rôles avec le PO et l'équipe
Découper, illustrer, spécifier : questions pour un BA agile
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
« Gérer les remboursements » arrive en affinage sous la forme d'une seule story, estimée à trois sprints. Quelle première tranche proposez-vous, et comment découpez-vous le reste ?
Une bonne réponseUn découpage vertical, où chaque tranche fonctionne de bout en bout. Par chemin : remboursement total d'abord, partiel ensuite. Par règle : sous un seuil sans validation, au-dessus avec validation. Par variante de données : carte bancaire puis virement. Il commence par la tranche la plus simple qui rend déjà service et vérifie chaque story avec les critères INVEST. Il peut citer la méthode SPIDR de Mike Cohn.
Signal d'alerteUn découpage par couche technique (base de données, API, écran) ou par tâche, qui ne livre rien d'utilisable avant la dernière story.
Question 2 · confirmé
Écrivez un scénario Gherkin pour la règle « livraison gratuite à partir de 50 € d'achat ». Que refusez-vous d'y mettre ?
Une bonne réponseUn scénario court et déclaratif : Étant donné un panier de 50,00 € TTC, Quand le client valide sa commande, Alors les frais de livraison sont de 0 €. Un seul comportement par scénario, un seul Quand, un Alors observable par le client. Pour les bornes, un plan de scénario avec un tableau d'exemples (49,99 €, 50,00 €). Il refuse les clics, les identifiants de champs et l'enchaînement d'actions successives.
Signal d'alerte« Je clique sur le bouton #valider puis je vérifie le champ frais », ou un scénario de quinze lignes qui teste trois règles à la fois.
Question 3 · confirmé
Comment construisez-vous la story map d'un nouveau parcours de souscription en ligne ?
Une bonne réponseEn atelier avec le PO, le métier et l'équipe, il pose la colonne vertébrale : les activités de l'utilisateur dans l'ordre (découvrir l'offre, simuler, souscrire, payer, recevoir son contrat), puis les étapes de chacune. Sous chaque étape, les stories de la plus nécessaire à la plus accessoire. La première ligne de version traverse tout le parcours avec une version minimale de chaque étape.
Signal d'alerteUne liste plate de fonctionnalités, ou une première version qui couvre parfaitement les deux premières étapes et laisse le reste pour plus tard.
Question 4 · confirmé
Critères d'acceptation et définition de terminé : qu'est-ce qui les distingue, et qui écrit chacun ?
Une bonne réponseLes critères d'acceptation sont propres à une story et décrivent le comportement attendu, écrits par le PO ou le BA avec l'équipe. La définition de terminé s'applique à toutes les stories (code relu, tests automatisés passés, déployé en recette, documentation à jour) et appartient à l'équipe. Il ne met pas « testé » dans les critères d'acceptation d'une story.
Signal d'alerteConfondre les deux, ou rédiger une définition de terminé différente pour chaque story.
Question 5 · confirmé
Que veut dire « documentation vivante », et comment l'avez-vous mise en place avec une équipe ?
Une bonne réponseDes scénarios exécutables, avec Cucumber ou un équivalent, qui décrivent le comportement du produit et sont vérifiés à chaque build : s'ils passent, la documentation est à jour. Les rapports d'exécution sont publiés et lisibles par le métier. Confluence garde le contexte, les décisions et les règles transverses. Il rédige ou relit les scénarios, les développeurs écrivent le code qui les relie à l'application.
Signal d'alerte« Une page Confluence mise à jour régulièrement », sans lien avec les tests.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
BA agile : les points qui font hésiter
Avec un product owner dans l'équipe, un BA agile est-il utile ?
Oui quand le domaine est riche en règles ou que le PO partage son temps entre plusieurs équipes, les clients et la direction. Le BA prépare alors les stories, les exemples et les scénarios, et le PO garde la priorisation. Sur un produit simple avec un PO disponible, un seul rôle suffit souvent. Ce partage doit être clair dans l'offre, sinon les candidats ne savent pas quel poste ils prennent.
La certification IIBA-AAC est-elle indispensable ?
Non, elle reste peu répandue en France. Elle montre qu'un candidat connaît l'Agile Extension du BABOK et les principes de l'analyse agile, ce qui est un bon signal. Elle ne dit pas s'il sait découper une story ou écrire un scénario Gherkin lisible. Un certificat Scrum de product owner apporte une information comparable sur la méthode. Dans les deux cas, l'exercice de découpage en entretien reste plus parlant.
Comment se passe l'évaluation d'un BA agile, sans code à écrire ?
Le test technique d'un BA agile ne demande aucun code. L'exercice comprend une story trop grosse à découper, une règle métier à illustrer par des exemples chiffrés et deux scénarios Gherkin à écrire ou à corriger. S'y ajoute un scénario mal rédigé, plein de clics et de champs techniques, à réécrire. Trente minutes suffisent. Le candidat explique chaque choix de découpage et les questions qu'il poserait au métier.
Un BA habitué au cycle en V peut-il prendre ce poste ?
Il apporte souvent de bonnes bases : recueil, règles de gestion, recette. Le changement porte sur le découpage, la taille des livrables et la place des exemples. Il doit savoir livrer une petite tranche utile plutôt qu'une spécification complète, et qu'il accepte de laisser des questions ouvertes jusqu'au sprint concerné. Une première expérience en squad, même courte, rassure sur le passage d'un mode à l'autre.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
