Business Analysis et Agilité Scrum

En fait on s’en fiche de comment ça s’appelle. C’est le rôle et les responsabilités de la personne qui sont importants.

Mon impression c’est que BA est compris comme un métier (et pas forcément le même selon les orga) alors que PO est un rôle dans un framework. Un PO reste le même rôle dans le framework, alors qu’un BA peut endosser plusieurs rôles.

Là où ça se complique c’est quand on parle de PO mais en dehors du framework Scrum, forcément il perd son sens Scrum et il est donc à redéfinir.

Bref, un mot ne suffit pas à se comprendre :grin: Surtout si on a pas le même référentiel.

5 « J'aime »

Et du coup, les échanges autour du rôle et des responsabilités de chacun ça c’est super intéressant et contextuel au système dans lequel il s’inscrit.

1 « J'aime »

Notre vidéo est publiée : Business Analyst : quel rôle en Agile / Scrum ? BA vs Product Owner / Developer / Scrum Master - YouTube

4 « J'aime »

Merci @jplambert et @const pour votre réponse et votre invitation. Je ne vais pas pouvoir me soustraire. Je serai avec vous sur le Live avec plaisir. Vous pouvez compter sur moi. :stuck_out_tongue_winking_eye:

1 « J'aime »

Oui @BenjaminJ , je pense comme toi, mais il y a tellement de projet avec des restes de silo ! :face_with_raised_eyebrow:

Génial !

Le lien pour nous rejoindre est ici : Prends le micro du Live ! | Business Analyst : quel rôle en Agile / Scrum ? BA vs Product Owner / Developer / Scrum Master

Marrant les sujets qui remontent tout seul… feature sympa !

Pour moi (et mon organisation) le BA dans le contexte Agile, c’est un BA et QA.
Tout le monde ne bosse pas forcément sur une « appli », certains évoluent dans un écosystème. IHM, API, référentiels, …
L’US et ses conditions d’acceptations qui constituent le DoD portent en général sur les cas nominaux. Rarement sur les effets de bords ou les adhérences aux systèmes conjoints. Le BA/QA me parait utile/nécessaire quand l’environnement nécessite des plans de test assez lourds et chronophages pour garantir le DoD dans un écosystème avec des adhérences entre applicatifs…

Citation
En scrum, c’est facile, « DANS l’EQUIPE »
C’est une discipline de plus que l’équipe doit prendre en charge. Et c’est à elle de s’organiser sur le comment.

Oui, mais …

Si le PO est issu d’une direction métier et que BA est issu d’une direction IT, que ce n’est pas la même personne qui distribue les objectifs individuels … ça va vite piquer

Bref, il n’y a pas de réponse universelle. Ca va dépendre des organisations cadre, du degré d’autonomie de l’équipe, etc

Pas le problème de Scrum, c’est le problème de l’organisation si elle n’est pas capable de donner des objectifs cohérent.

Il n’y a pas de ba dans une équipe Scrum. Juste un PO, un Sm et une équipe de développement.

Le PO est dans l’équipe Scrum . La même que le sm et l’équipement de développement, les autres sont des externes, éventuellement partie prenante.

Ma réponse va encore paraître peu Diplomate.
By the book.

Mais Scrum c’est fait pour cadre d’une équipe qui développe du logiciel, qui peut éventuellement s’attaquer à autre chose qu’un logiciel pour autant que ce soit à la portée de leur capacité en gardant une taille et raisonnable. Ça n’est pas fait pour résoudre les problèmes d’une organisation mal organisée ou archaïque ou dissonante…
Il y a d’autres cadres ou outils ou méthodes pour cela.

Il y a aussi des alternatives à Scrum si on a pas envie de faire du Scrum.