On a truely agile project where the business is performing the role of the product owner, is there still a role for the Business Analyst? The product owner would do the functional testing as soon as the user story is developed and document and prioritise the user stories.
In this case which I must add I haven't experienced yet and with high performing, self motivated developers I am struggling to see the role of the traditional business analyst?
Absolutely, 100%. There is still a need business analysts:
Quoting from a source:
The business analyst involvement in agile projects, unlike that of the project manager, is not limited to the period of time when the projects are active. Business analysts provide continuity for companies from cradle to grave by working with portfolio management teams to make sure the most valuable projects are being invested in, providing oversight during projects, and finally measuring actual benefits after projects are completed.
Have a look at these links:
I worked on a project whereby there was no BA working with the developers and the product owner was completely useless. The pain it brought into our lives was far greater than the pain of having a BA ;)
I would call our project fairly agile (although not SCRUM by the book for various reasons, but reasonably close, and improving - of course, whether it is agile "truly" enough, can be debated by methodology purists ;-) Anyway, we do have a BA, and I am happy about it.
It is an in-house legacy web app, used by thousands of agents in dozens of countries. The requirements are pouring in from many country representatives, and since each country inside our corporation has their own budget and agenda, prioritizating tasks is not a simple issue, I believe there is a lot of managerial negotiations behind (of which luckily I don't sense anything). So we don't have a dedicated product owner - practically our tech lead plays the role as much as it is needed. Which is not very much, since the app has been brought back from terminally ill status by our team and is still shaky, so the larger part of our work is bug fixing, refactoring and other tasks to stabilize and clean up things.
Our BA has been working at the counter for a couple of years, also with the back-end system our app depends on, so he knows more about the inner workings of these beasts, and also the processes used on the field, than any of us developers. This is especially important since there is very little written documentation, let alone specification of what our app is supposed to do. Often we have trouble figuring out whether the particular behaviour of the code is a bug or a feature.
So he helps us identifying bugs, moreover does a lot of requirements gathering, squeezing bits of info out of various country representatives. He also does testing and verification for us. We would definitely have a hard time without him.
We do have at least one or two BAs in our SCRUM team. They fill the role of Product Owner not being available on a daily basis to answer functional questions. Because:
They have been in meetings with the Product owner in developing the Product Backlog.
They have a better sense of relative priority of user stories in a Sprint compared to developers and QA
They help out with high level design of features in current sprint to the extent of smoothing out incorporation of user stories that most likely will be coming 3~4 sprints down the road.
It's really a question of how complex your Product Backlog Items are and how much analysis work they take to put them in a state where the Team can commit to them in a Sprint.
The Product Owner owns the Product Backlog and is responsible for managing it, but that doesn't mean she is the only person doing business analysis-type tasks. The PO's job is to make decisions about value and priority. Other team members can (and usually do) help provide the data to fuel those decisions.
Business Analysts often help groom the Backlog (and on complex projects, they probably have to); the Product Owner is one who is in trouble if it isn't maintained. The role of Analysts certainly changes in Scrum teams (Chapter 8 of Mike Cohn's Succeeding with Agile has a few pages on this), but having a non-PO Analyst on a team can still be quite useful. (I wish my current team had one.)