Business Analyst in Scrum
In traditional approaches, the Business Analyst gathers the requirements months or years ahead of the team. Clearly that doesn’t work in an Agile world. Scrum doesn’t define any traditional roles inside the team: BA, QA, DBA, Dev, UX - instead everyone is a Developer or, better yet, a doer. This creates discomfort, but also opportunities.
“What is the role of a BA on a scrum team? My team and their BA are struggling to know what falls on the PO responsibilities vs. what falls on the BA responsibilities.”
This question, or a variation of it, is one that often comes up in training workshops and our Lean Coffee sessions. Some options I’ve seen work well:
- BA is the Product Owner
- BA works inside the Scrum Team assisting the Product Owner flesh specific details. (This happens most often when there is one PO for multiple teams working on a single product, in which case the PO is focused on Product Strategy/Prioritization not PBIs/User Stories)
- BA participates with QA and Programmers to define acceptance criteria - in the BDD style
- BA cross skills and helps with QA, this is a natural outgrowth of the previous step
- Some cross skill into UX work and, rarely, others cross skill to programming