The Agile Extension to the BABOK® Guide is well worth the read, and I’d encourage any business analyst heading into an Agile project to take the time to give it serious consideration.

The section entitled “What makes a BA Successful on an Agile Team” starts off with this paragraph:

The very nature of agile approaches requires all team members to be operating at a very high level of competency, skill, and effectiveness. This is especially true for business analysts. On successful agile teams, business analysts are an integral component of the delivery team. They are active participants, if not the actual facilitators of planning, analyzing, testing, and demonstrating activities. (The Agile Extension to the BABOK® Guide, Version 1.0, p.8)

Having worked with several companies new to Agile, I’ve been able to observe what happens when you have a good BA, and what happens when you don’t have anyone filling that role.  Having a good BA, especially when the product owner is remote or hard to reach, provides the grease to keep the development engine running. As the Agile Extension notes, there are a variety of ways a business analyst can be engaged on an Agile project, including acting as a the product owner when they are empowered to make decisions on product features and priority, or acting as surrogate product owner in situations where the business product owner is not available. (ibid.,  p. 6)

In my career, I’ve experienced what it is like to be that remote product owner.  My development team was located 12 ½ hours offset from my time zone, and I never actually got to meet the team.  Not only did we have time barriers, but there were different levels of language ability as well.  I didn’t speak their native language at all, so I had to depend on their ability to understand my spoken and written English. I found I had to do what the Agile Extension recommends – that is, I needed somebody there with the team to act as my surrogate.  They would clarify requirements with the team, keeping me apprised of the questions that arose and their answers to those questions.  It took some time for us to get ourselves used to how each other worked and thought, but eventually things worked pretty smoothly.

So, my advice is to have the BA and the PO meet up at the start of the project and get to know each other.  Work some example stories together and figure out your strengths and weaknesses.