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 struggle to know what falls on the PO’s and what falls on the BA’s responsibilities.”

Part of the challenge is that the traditional approach of the Business Analyst going out to gather requirements disappears. Long-requirement documents are replaced with conversations with stakeholders before we start working on a problem. The core problem they want solved becomes the User Story. The details become the acceptance criteria.

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 to flesh out 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 using the BDD (Behaviour-Driven Development) collaborative approach. BDD leverages the detail-oriented skills of the BA to ensure we’ve covered all of the edge cases.
• 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

So we move away from having a distinct role named Business Analyst, towards a team member focusing on solving the customer problem, not gathering requirements.