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 as 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
I like to describe product ownership as doing three main things:
- Focus everyone on outcome over output
- Build and maintain a 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 by 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 a 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
If you’re a business analyst but not filling the product owner role that does not mean you don’t have a place in an Agile setting. There’s a fairly common model where there is both a product owner and business analyst who work on the same team. This model often occurs where the product owner makes decisions and the business analyst builds and maintains shared understanding. This model is also prevalent when there are multiple teams working on a complicated product.
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
I’ve also seen business analysts slide into the role of coach or scrum master. This may be a good fit for you if you have strong facilitation skills and enjoy helping teams work through their team dynamics issues. You may also find this route a good way to go if you have a product owner who doesn’t have a great deal of experience building shared understanding with a team.
Skills are more important than titles
When it comes down to it, there isn’t much sense in slotting someone into a particular role on an Agile team based on their existing title or position. You really need to consider what their skills and past experience are and put them in a position to make the best use of those skills when working on self-organizing teams.
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 who 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.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
