“What is the Role of a Business Analyst in Agile?”
I see this question asked quite a bit. I’d like to suggest that rewording the question may be a bit more instructive. Instead of wondering what is the role of a business analyst in agile, you may want to ask the question “how can people who have filled the role of business analysts in other settings contribute effectively in an agile setting”?
Various agile approaches treat roles differently. Since Scrum is the most frequently adopted, it’s the model most often associated with agile in general (right or wrong). Scrum effectively did away with roles altogether, except for three: Scrum Master, Product Owner, and Team. Folks who have previously filled business analyst roles can and often do find themselves filling anyone of those three roles, not because they were a business analyst, but because of their personal skill sets. Typically though, people with a business analysis background get involved in some form of product ownership.
Context tends to play a big part in determining how someone with business analysis skill sets contributes in an agile setting. My friend Todd Little, who has a great deal of experience leading development organizations in an agile setting put the following graphic together to show the different models that exist in actual practice.
The first model where the Product Manager or Business Leader is the Product Owner tends to be more common in Product Organizations than in internal IT situations because the person filling that role has business analysis skills (often in this case referred to as Product Management skills) as part of their job.
In the second model, the Product Owner is a separate role from the Product Manager or Business Leader, but reports up through the business part of the organization. This model can be seen in both product organizations and internal IT settings. If the organization had business analysts sitting in the business units, they may often see their titles changed to Product Owner. In this scenario, the Product Manager/Business Leader sets the roadmap and does global prioritization, while the Product Owner handles more local prioritization and is mainly responsible for writing and clarifying user stories. This model often shows up in organizations where there weren’t business analysts in the engineering/IT part of the organization (shown in the model above as Product Development).
The third Model has Business Analysts on the IT side and no specific Product Owners. This model tends to be more prevalent in internal IT settings than Product companies and is usually what happens when the organization had business analysts that belong to the IT organization. Often the business analysts in this setting end up playing the role of Product Owners, sort of, in that they are working to make sure that decisions happen, though they may not have the decision making responsibility themselves. In this case, the Business Leader sets the roadmap and does global prioritization (often only after nagging from someone sitting in a business analysis role) while the business analyst again does local prioritization (sequence of items on the backlog of the team they are working with), and writes and clarifies stories.
A variation of the third model which I have seen is where there is a Product Owner on the business side who is responsible for making sure a roadmap is set and there is some global prioritization (although they don’t have the authority to make those decisions themselves) and the BA still takes care of their local responsibility. This model most often occurs in Internal IT settings where the Business Leader feels so loaded down with other responsibilities, that they need someone to handle the Product Ownership aspects of their responsibilities. In this model, the person on the Business Side is titled Product Owner, and the folks doing product ownership on the IT side are often titled Business Analyst. This model can lead to a great deal of overlapping responsibilities and large gaps, mainly because each person assumes the other is taking care of a particular issue and so neither end up taking care of it.
One way to determine what model to pick is to explicitly who is going to do what. RASI charts are good tools to guide this conversation. You can start by identifying what specific roles are expected to do, then change things based on the actual people on the team and their skill sets. You may find that the actual activities that people undertake differs a bit from the role they are filling is usually expected to do. In some settings this is viewed as one person filling multiple roles, something which I did quite a bit when I was contracting.