Agile Q&A: What Do Business Analysts Do on an Agile Team?

by Kent McDonald

I have the opportunity to talk to business analysts quite a bit, and the conversation usually turns to the topic of Agile.

More often than not, the question that comes up is “there isn’t a business analyst role mentioned in Scrum. Does that mean that there is no place for business analysts?”

The short answer is no.

Scrum mentions three roles — team, product owner and scrum master. There’s a difference between titles (what I would generally describe Business Analyst) and those three roles. Regardless of your title, you can fill one or many roles depending on your organization, your skills, and your past experience.

Yes, I realize that more and more organizations blur those lines by explicitly posting job ads for scrum masters and product owners. That does not change the fact that having a background as a business analyst does not preclude you from acting as a product owner, member of the team, or scrum master. In fact I’ve seen examples of all three cases.

A product owner

  • Focus everyone on outcome over output
  • Build and maintain shared understanding
  • Make decisions

There are many cases where business analysts fill the role of product owner and do those three things. In order to make that happen, a business analyst needs to be able to make decisions.

If you’re a good BA you’re already doing the first two items. You focus everyone on outcome over output by helping your team identify the problem to solve rather than just fixating on a solution. Project chartering is one way you can make that happen.

You build and maintain shared understanding through applying your analysis skills in creating your product backlog, refining the backlog, and working with your team to build clarity around your backlog items.

In some cases you may not be in a position to make decisions yourself. This generally occurs when you deal with several stakeholders who don’t own your product but have considerable say in what it looks like. In those situations, you may still be a product owner, but the third item from above is probably better described as “Make sure decisions get made”. If you do your job right, your team will not experience interruptions due to delays in decision making; they just may not have insight into how those decisions got made.

A member of the team

You may have become a business analyst after having been a developer because you wanted to interact more with stakeholders and users. Once your organization starts working in an Agile fashion where anyone on the team can interact with people outside the team, you may find you can have the best of both worlds by doing development work and working closely with stakeholders and users.

A scrum master

Skills are more important than titles

It may be very clear what you should do when your organization adopts Agile. It may not be as obvious and you may need to acquire some new skills or take a different perspective on how you approach work. Or you may realize that you don’t want to work in the fashion that your organization is headed and it’s a good time to look for different opportunities. It really depends on your skills and how you work best. It’s an individual thing, not across the board based on titles.

This has two important implications.

If your organization gets advice to get rid of an entire group of people because of their title, the people to get rid of are the ones that gave that advice. Look at their skills, look at their ability to adjust. Look at their willingness to learn. Don’t just let them go because they’re business analysts (or managers, or project managers, or…).

Realize that not everyone wants to work in an Agile manner. I have met business analysts who place a great deal of their self worth in producing wonderfully extravagant requirements specifications or UML models. They may be able to adjust to an iterative and incremental approach to working. They may not. Give them a chance and if it doesn’t work, help them find something where they can be successful.

Agile approaches place a large emphasis on the people doing the work and how they interact. When you give people a chance to do what they have the passion, ability, and capacity to do, you are living up to that value. People with business analyst backgrounds can contribute a lot of value to your team and organization. They just need an opportunity to demonstrate that.

Get the best content on Agile Alliance:
Sign up for our Q&A curated content newsletter.

Read more great articles like this in the Agile Alliance blog!

Originally published at on January 29, 2019.

Agile Alliance is a nonprofit global member organization, supporting and serving the Agile community since 2001.