Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Business Analysis/Requirements Management
Using a BA in Agile

We are having an ongoing debate in our PMO about wether we need BA's in an agile scrum teams or if we just drop them and let the traditional methodology run.

I have seen success in using them to get velocity put once a team is tuned in there is little value to have them in the team. What have other people done?
Sort By:

Just to comment I am working facing this type of things from long time ago, including it working with the IIBA and the PMI on this type of things. First, BA is not defined as a role inside Scrum then is you add that role you are not using Scrum. No problem with that, you are using your own customization of Scrum, I did that lot of times, but it is not Scrum. Second, because BA is a role, you will find inside the Scrum role definitions how you can map BAs to Scrum roles. Just to put an example in my actual work place: the same person is assigned to more than one project at the same time and those project are running using agile based (Scrum and DSDM) and non-agile based approaches. So, project managers, BAs. BRM are there. Third, my recommendation is taking a look to the IIBA software or agile extension document and take a look to DSDM method because the method has the BA role defined and I think when you read the definition it could help to map it to Scrum roles.

BAs and Dev do not necessarily have the same abilities. I've known many highly talented developers who didn't want to speak with a customer, and couldn't elicit requirements. I am an accomplished BA, but coding is not for me. If your developers are also competent at BA tasks, then perhaps you don't need BAs on those projects.

There's no rule that says you can't have the BAs go onto other projects when they are no longer needed. We do that with developers with specialized skills all the time.

There's no rule that says you must have a BA, and there's no rule that says you can't.
I like Bob's response. If a team thinks a BA could help them, assign a BA. (Assigned BAs often work with the product owner's team.) If the same team decides they no longer need one, then remove the BA from the team. In an Agile organization with self-organizing teams, this would be true with every other person on the team as well. Your PMO shouldn't pre-determine what each team should look like.

Business analysis is a critical skill set for successful product ownership. Many of the POs I've worked with don't possess that skill set, so BAs support them to ensure the "right" requirements are being progressively elicited and analyzed.


Currently have BA's in the scrum teams. Works really well as an intermediary b/t the business (PO) and Dev team.

I am running a project within an scaled agile framework. There is no problem at all to have a BA role included as this helps the product owner in prioritisation work.

It would depend on the existing skills that your project team possess and whether they can fulfil the gap that would exist if you drop your Business Analysts. It would be a personally choice so that if you see the need to keep them let logic dictated and keep them but if you think they are not contributing anything to the team and are just an additional strain and burden on the team, well then you could reallocated them to somewhere else where the skills are needed.

Officially there is no role for a Business Analyst in Scrum teams.

They can be a separate team, supporting the Product Owner in writing and clarifying the user stories.

Andrew - i sort of can relate to what you say. I had a similar instance and not sure if this could help. This was a large program (I was the Programme Mgr) for one of our prestigious customers. We were moving away from traditional waterfall to Agile/Scrum based project engagement. During the first few sprints and iterations, having a BA on the scrum team helped quite a lot. We had the BA groom the stories, ensure the team understood the requirements well from a development and testing perspective. And the BA would look at testing the outcome of the scrum team each sprint - end-to-end verification. This would ensure that the issues during Integration were reduced.

As we progressed for a bit longer - was about an year I think - we then felt the BA role was now becoming a bottleneck for communication. The development and testing team had scaled a lot on the functionality and hence the use of the BA in the scrum team did not make much sense. But what we also did was elevate some of the BAs in the team to move to the role of Proxy Product Owner. This way they could span across multiple scrum teams (we looked at this more from a Feature perspective). And hence they would think of the big picture from a functionality perspective - something no one else in the team had time for (considering that this was a 2 week sprint and a long running program).

Please login or join to reply

Content ID:

"I like Wagner's music better than anybody's; it is so loud, one can talk the whole time without other people hearing what you say."

- Oscar Wilde



Vendor Events

See all Vendor Events