Le rôle de Business Analyst Agile est de plus en plus populaire au sein de nos équipes agiles. Mais comment définir ce rôle par rapport aux autres rôles connus dans les équipes agiles ?
Qu’est-ce qu’un Business Analyst ?
Le Business Analyst (BA) est dans les méthodes traditionnelles, l’interface entre l’équipe IT et les équipes métiers. Il analysera les processus d’information afin de faire de bonnes spécifications fonctionnelles tout en suivant les décisions prises par les décideurs de la stratégie.
Le Business Analyst qui arrive en Scrum ?
Quand le Business Analyst arrive dans un univers Scrum, nous estimons qu’il peut se positionner sur un des 3 rôles suivants :
Business Analyst en Product Owner
Il n’est pas rare de demander au Business Analyst de prendre un rôle de Product Owner ; cependant il devra être formé car ce ne sont pas les mêmes métiers. Cependant c’est une suite logique dans les transformations agiles.
Attention par contre de bien amener ce Business Analyst à devenir le membre de cette équipe même si il est considéré comme un membre des unités « métier » de l’entreprise.
Un Business Analyst Agile en expert
C’est le positionnement le plus intéressant du Business Analyst (BA) dans un projet Scrum voire Agile. Le BA va devenir l’expert d’une partie spécifique du produit qui exige une véritable expertise.
Par exemple, si vous sortez une application de comptabilité, le Product Owner n’aura pas forcément l’ensemble des expertises nécessaires pour performer sur l’écriture des user-stories et de ses règles de gestion. Sur des applications complexes, il est rare de pouvoir être expert sur tout. On prendra donc un (ou des) BA qui sera l’expert de la partie spécifique Bilan et Compte de résultat par exemple.
Il aidera ainsi le Product Owner (PO) à l’écriture des user-stories qui seront sur son expertise et fera parti de la PO Team. Sur certains produits, l’analyse des processus sera plus longue que le temps de développement mais grâce à son travail, les développeurs pourront développer rapidement l’ensemble des règles écrites très clairement sur les user-stories.
C’est ce que j’appelle un véritable Business Analyst Agile.
Cependant, les décisions finales reviendront au Product Owner en cas de désaccord.
Un Business Analyst Agile en Proxy Product Owner (Proxy PO)
Ce cas est plus rare, mais il est possible de voir le Business Analyst devenir le Proxy PO du produit. N’hésitez pas à voir l’article déjà proposé précédemment sur ce rôle pour le comprendre.
Article : Qu’est-ce un Proxy Product Owner ?
Conclusion Business Analyst Agile
Les Business Analyst Agile est un rôle qui peut apporter énormément à des équipes agiles surtout quand on est sur des applications relativement complexes.
En effet, il ne faut pas exclure ce rôle des organisations agiles même si ce rôle n’existe pas de base dans des équipes Scrum.
Bonjour,
Un petit REX de l’arrivée de BA dans une équipe SCRUM et plus particulièrement avec l’équipe de PO : Il a été très difficile pour les PO et BA de trouver leur place respective dans le flux de production. Ceci en grande partie parce que l’activité de recueil/cadrage avait été menée par les PO jusque là. A la suite d’un certain nombre de tensions, je leur ai proposer de co-construire un workflow et de faire un DOR et un DOD de chaque étape. Ce qui nous a permis de matérialiser un kanban, poser des rituels pour l’amélioration continue et de créer implicitement une nouvelle équipe agile de BA&PO.
Et avec le temps, tu sens que le duo fonctionne ?
Bonjour,
Peut-on parler aussi de Growth Marketer ?
Le Growth Marketer est un rôle encore différent du Business Analyst.