One More Time, What is the Business Analyst Role in Scrum?
There is no special role of business analyst in Scrum. However, BAs can add tremendous value bringing theirs skills, if willing to be scrum team members.
A frequently asked question when I am working with teams moving to Scrum is what is the role of business analyst role on a Scrum team.
Usually it comes from someone with the title of business analysts but it may also come from the manager of the business analyst team. Immediately I know that there are going to be challenges.
Business analysts are generally smart, detailed oriented professionals who are frequently high-performers.
They rarely have positional power so tend to build strong relationships and deep understanding of the nuances of the business to provide real value. They facilitate meetings and workshops and they are usually great at communicating their ideas and concepts like detailed process flows.
Before I dive into my arguments for why Business Analysts don’t really fit well on Scrum Teams, I’d like to point out that others have different opinions (and perhaps deeper expertise) on this subject.
Kent McDonald is an agility expert and someone I’ve known for a number of years and he recently wrote the book, How to be an Agile Business Analyst. You can get a taste for Kent’s thoughts in this blog post What is an Agile Business Analyst. His primary focus is the thoughts and behaviors of the BA.
There are No Specialists like Business Analysts in the Scrum Framework
My biggest challenge with the business analysis in a transition to Scrum is that they frequently have difficulty acting as a development team member.
I don’t know if they dislike the generalist role of team member or they like being special but either way they generally resist being part of the team. They like the concept of the specialist role and don’t want to be a scrum development team member responsible for getting all the work done.
As a reminder, in the Scrum Framework there are just 3 roles: product owner, development team member and scrum master. The last of those — development team member — is responsible for doing all the work to take backlog items to done within a sprint. There is no specific role for a business analyst.
In fact, eliminating specialist roles is a key part of moving to Scrum. The specialist roles create bottlenecks and inefficiencies as people are careful to spell out what is “my job” and what is not. Having people on a team who are unwilling to do certain jobs is suboptimal.
In addition, the way Business Analysts have traditionally worked is in conflict with the way Scrum teams work. The BA is often responsible to go out and gather requirements. They compile these into long, detailed documents and then they hand those off to developers.
Yep, it’s the telephone game being played by adults. Putting a bunch of details into a document and handing it off to others is a surefire way to build the wrong thing.
They tell me proudly that they play the ‘translator’ role since they can speak to both the business and technology. Really? Since when don’t we expect all team members to speak to both business and technology?
On a development team in Scrum, everyone is expected to understand the business. And the remaining work is everyone’s job. Analysis, design, development and testing is the responsibility of the entire team.
That doesn’t mean everyone is equally good at it or that it would be efficient for everyone to do every job. It is just a matter of ownership and teamwork.
A Business Analyst Manager Makes it Worse
Frequently the separation and specialness of the business analysts is reinforced by a business analyst manager who is responsible for all the BAs.
This introduces differing loyalties, conflicting reporting lines and objectives and an even weaker commitment to the team success. The business analysis manager will usually be threatened by any suggestions about organizational changes.
4 Anti-Patterns for the Business Analysts in Scrum
I’ve seen some approaches that various organizations have tried to use to address the business analysts when moving to the Scrum Framework. Let’s look at 4 common anti-patterns of using business analysts in Scrum teams.
- BA as Proxy Product Owner
- BA as the Connector
- BA as the Glue that Holds Multiple Teams Together
- BA as part of the Development Team
Let’s take a look at each of these in detail and explore why there might be problems with each of these.
Anti-Pattern #1 — BA as Proxy Product Owner
Some organizations use the business analysts as a stand-in or proxy for a product owner. They either cannot find an appropriate product owner or the best person in the organization is too busy or not interested in the role. So they have a business analyst perform the role.
While it may provide a person who is knowledgeable and has the bandwidth, this approach usually results in subpar performance. The proxy product owner is not the real owner, they often sit in technology, they aren’t empowered and they frequently get overridden by others.
Anti-Pattern #2 — BA as the Connector to the Business
Another approach that I have seen used is to put the business analysts outside the development team and let them continue to operate as they always have. This includes them going out and collecting details on business needs.
Since they are using agile, they will write their long requirements in Jira as a faux user story. These user stories are then handed off to the team with no real connection or exposure to the stakeholders, users and subject matter experts.
When questions come up, it is the BAs that go back to those experts to get answers. And that generally results in multiple trips since the BAs don’t always have the context to get the details correct on the first pass.
The problem here is the separateness. In this approach, responsibility for ‘grooming’ the backlog often falls on the BAs and they do this by themselves, without the team.
There is no end-to-end ownership; the business analysts have no real skin in the game for team success. We have significant information loss whenever we have a handoff. And it gives the development team an excuse for not delivering — we are waiting for the BA to write the user story.
Some people became the “BA” because they knew a lot about how things worked in a particular area. Maybe they used to work in that area. The risk is that their knowledge may be out of date.
Anti-Pattern #3 — BA as the Glue that Holds Multiple Teams Together
This approach fails for the same reasons as the previous; separateness and handoffs. In this approach, a single business analyst is responsible for maintaining alignment of multiple Scrum teams. They make sure that the backlog items have clearly defined dependencies and that each team is aware of what the other is working on.
By making the BA the glue, we remove an important direct communication channel between the two teams. The teams are perfectly capable of coordinating with each other if they are taught it or supported to do it.
Anti-Pattern #4 — BA on the Development Team
This would seem like the best approach — just put the BA on the development team. And this can work, as long as we completely eliminate the BA role and title.
If the BAs on the team are able to still call themselves BAs, they are likely not integrating. They are going to just pick and choose and do the work that a BA would normally do. There may or may not be exactly the right amount of that BA work to be done on the team which creates an inefficiency.
You see it in the daily Scrum meeting for teams with that BA role on it. The BA will typically say something like, I don’t have any tasks on the board so just let me know if you need my help with anything. WTF???
What to do with your Business Analysts Instead
As noted at the top, business analysts tend to be smart, detailed oriented and valuable. Having a business analyst on your team can be critical to your success. If they are properly positioned to add value.
- Eliminate the title of business analyst, and all other specialty roles. Team members should still do business analysis of course, but it isn’t just one person’s job, or all one person does.
- Eliminate the department and manager of business analyst. Otherwise, that manager and department will undermine the work of the teams and the ability for former business analysts to perform within the team.
- Encourage the business analysts to teach others their skills of modelling, analysis and communications. And it is not just BAs, all team members should be teaching their skills to others and learning from others.
- Provide opportunities for BAs to become Scrum Masters. In my experience, they often do a good job in this role. See my description of the Scrum Master role here.
Note that this article could just have easily been called, “What is the QA role in Scrum?” or “What is the PM role in Scrum”.
⭐️Thank you for reading. If you enjoyed this article, feel free to hit that clap button 👏 to help others find it.
Let’s connect on Twitter or find me professionally in Linkedin.
Leave a comment below if you have any questions, and subscribe to receive the latest updates in Agile and Scrum.
Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.