One More Time, What is the Business Analyst Role in Scrum?

One More Time, What is the Business Analyst Role in Scrum?

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.

My biggest challenge with the business analysis in a transition to Scrum is that they frequently have a lot of difficulty accepting the role of 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.

There are No Specialists like Business Analysts in the Scrum Framework

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.

  1. BA as Proxy Product Owner
  2. BA as the Connector
  3. BA as the Glue that Holds Multiple Teams Together
  4. 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

BA as Proxy Product Owner

Some organizations use the business analysts as a standin 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

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

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

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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”

This Post Has 12 Comments

  1. Great article. interesting stuff to read. I was searching for this topic and finally got on this site. thanks for this post. please share the latest updates. as a business analyst, this topic is so important to understand.good luck for next article.

  2. The reality on the consulting side is clients want agile, don’t have POs and don’t know scrum. So the BA becomes the proxy PO as you mentioned. However you aren’t giving the Modern BA enough credit. We hold scrum PO certs, we embed with the business and often have the capabilities to improve their current business processes and don’t just shoving old waterfall requirements into Jira.

    You are emphasizing the dogma of only three roles instead of thinking about what actually makes sense for getting to working software. If the PO is an inexperienced analyst that the business made decided to make the sacrificial lamb, and you want to stick with 3 roles and not have someone to coach then, good luck delivering a system that works on the other side.

    1. Andrew, thanks for your comment!

    2. Thanks Andrew! You nailed it!

  3. Thanks for writing this but I feel like the article is from a purist approach. When a large company starts transitioning from the Waterfall model to the Agile model, the BA title can’t simply and easily just be removed, there are years of experience which makes them valuable assets to the team/company, thinking especially of senior BA roles. The alternate “anti-patterns” seem to work with the “proxy” being the most logical, I agree that BA’s become great scrum masters but they are excellent support to the scrum master, product owner, and dev manager, They are stand-in’s to the respective roles, the mid-fielder in a soccer team. driving requirements between business and development, facilitating important/key discussions for requirements/user stories to move forward.

    1. Chris, thank you for your comments. I agree that senior BAs are valuable assets to the team and company and I am not suggesting the person be removed. What I am suggesting is that if you are going to use Scrum, the person with those BA skills become a team member and help get the team’s work done. It would be ineffective for them to be idle waiting for “BA” work to show up rather than pitching in to help the team.

  4. Sounds like you’ve worked with a lot of crappy BAs and BA managers in your time. That’s unfortunate.

    It also sounds like you’re interested in keeping all of the functions of a skilled BA on an agile team but not having anyone with responsibility for those functions or anyone at a higher level to provide coaching and skill improvement for those individuals.

    If you have had success with no analysis being performed on stories or business need until a story is brought into a sprint, I say good for you. I’d be interest in learning more. But to suggest that someone who has been in a business unit for however long and has been voluntold to “go be a Product Owner while still doing all of your old job” is going to be good at looking at things objectively AND analytically AND performing the requisite analysis AND writing helpful user stories and acceptance criteria, is indicative that you’re living in a world that few of us are privileged to know about.

    1. Hi Todd, thanks for your comments. I will have to go back and look at what I wrote but I don’t think that I said 1) I worked with a lot of crappy BAs or 2) that no analysis is done prior to stories being brought into the sprint.

      I think what I said was that the BA skills are essential and the entire team will benefit from having those skills. This is preferred over one BA acting as specialist on the team that is the only person who does the analysis and they do nothing else. Having one person be the BA creates a bottleneck. It is also inefficient because they are a go-between and they create a handoff which is a recipe for rework and waste.

      You can look at the Standish Group Statistics or any other survey on project failures to see that the biggest reasons for failure are related to requirements. The solution that was tried for years was to have a BA create better requirements documents. Unfortunately, that has not solved the problem and won’t. What will solve the problem is shortening the distance between those using the solutions and those making the solutions. The more distance, people and time between user and maker, the more likely the team is to be building the wrong solution.

      Thanks for weighing in and I am glad you are a reader of the blog.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu