Vitality Chicago Logo

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

One More Time What is the Business Analyst Role in Scrum2

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.

  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”

Agile PM book
Agile PM book

43 Responses

  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.

  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.

      1. “It would be ineffective for them to be idle waiting for “BA” work to show up rather than pitching in to help the team.”

        Hahahahaha… hahaha… haha…ha… !

        You’ve clearly never worked as a ‘BA’ on a scrum team – the ‘modern’ BA is a Proxy PO, Scrum-master, UI designer, content-writer, process analyst, technical analyst, solution architect, QA – there’s ALWAYS something for us to do!!!

        My life is spent trying to keep one step ahead of the steamroller of the dev team in terms of getting tickets ready for the next sprint… it’s relentless, frantic-paced work that only people with excellent cross-discipline skills can deliver.

        1. Indeed. This article shows a real lack of real world experience of actually delivering software. It’s actually borderline offensive when it talks about not being “part of the team”. You can’t expect every member of the development team to understand, certainly not initially, a complex business domain. And it’s not efficient for them to try and do so. That’s where the BA helps immensely. As a BA I certainly “pitch-in” to the team, writing user stories, sharing knowledge, working with developers, testers, POs, UX, UR and content people to help formulate ideas and yes, build a product together – as part of a team.

          1. Hi Nick, thanks for weighing in with your perspective. I think if you read the comments, there are clearly two camps:

            1) BAs (like yourself) that are accustomed to writing backlog items, providing details and creating a bridge between customers and developers.

            2) Others who have worked with teams where the BA was not the go between, or where they did not have BAs and where the developers on the team had conversations directly with the PO or SME so that they clearly understood the need and the requirements. These people believe that it is very possible for developers to understand the complexity of the business needs and develop solutions for them without translation from a BA.

            I obviously land in the second camp. And though I wasn’t trying to offend you, if you do get borderline offended then that is OK as well.


  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.

  5. Hi Anthony, thank you for your article. I completely disagree with you on a number of points you are raising, but for you to understand why I am disagreeing, please read my article published on modern analyst. My original title for the article was ‘In Defence of Business Analysis’, because I feel that our BA profession needs to e defended from points of view similar what your article puts forward.

    1. Edward, before I take on your reading assignment, would you please elaborate for me which points from my article you feel you need to “defend against”? It was not my intent to attack or debase business analysts, only to describe some of the issues that occur when they work on agile teams.

  6. I don’t know Anthony, the points in your article all seen very utopian. I think the whole reason roles like business analyst and project manager exist is because your average development team isn’t good at tracking dates or gathering requirements or communicating with customers and stakeholders. And instead of staying “the dev team should do all those things” most businesses assign these duties to other people so the dev team can focus on developing.

  7. Reading your article makes me imagine a meeting with the business (as the product owner) and the developers. You are assuming that everybody does a great job, but my experience as a Business Analyst is a very different one.
    Most Businesses are not in the market of creating IT Solutions. Those Businesses are looking for IT to help them do their job. They don’t know anything about IT Development. In most cases, many, if not all, of their current processes need to change when integrating with an IT Solution. Developers will have questions the Business could not answer, even if they wanted to. The Business Analyst comes into play on one side to support the Business in the change of their processes, answers questions the business might have and helps to identify where IT can be of real value to the business. The Analyst creates a picture and translates this to the Development team.
    Creating documents is the smallest part of an Analyst, but an important one. Most developers today are young people with little or no experience in business. Most of them will struggle to understand the implications and wrong decisions or products might have on the business. Bringing it together is part of an experienced Senior Business Analyst.
    I can imagine your approach to work in very small projects, but with a team of 10 developers or more, I have never seen this working.
    When I take part in Scrum meetings, I listen to what is said and my core question is “How can I help the team to progress further and better?” I am not waiting for someone to tell me what to do. I am always present and support each team member to my best abilities. I found this the best way to support the team and keep things on track. Identifying possible risks or misdirection early is key here.
    Also in larger projects, there isn’t just one product owner, There is a bunch of people involved in the process on the business side. And if some decisions might impact other departments they will have to be discussed before a decision can be taken. Companies do not rum Scrum style

    1. John, thank you for your comments. I am not sure I agree with your points that the developers don’t know about the business and the business doesn’t know about technology or your conclusion that someone like the BA needs to play the go-between.

  8. Anthony, your approach as described will be fine in smaller teams. As you get into enterprise organisations you end up in a situation where the product manager is too commercial and not able to work directly with devs. We have experimented with many models such as having devs interface directly with product managers to try and elicit and elaborate stories, but we have found that not all devs are the same. Inevitably some hate doing this, some don’t mind it and others enjoy it. So we end up with proxy POs, in some teams a single proxy PO deals with the product manager, and in others a few of the team act asproxy POs and deal with the product manager. It’s not perfect but it works, and far better than having the entire team working directly with the Product manager. We have about 100 scrum teams and this has been the model we have settled on.

    Now if you have BAs in an organisation you have a few choices – get them to become scrum masters (but not all BAs enjoy that), get them to become team members and act as proxy POs (but we would need them to also do dev/test like the rest of the team or we end up with specialised roles in the team) or finally you help them become product managers. End of the day we don’t want specialised BA roles except in exceptional circumstances.

  9. It is my experience that modern Business Systems Analysts do not write long requirement documents and then hand it off to development. Our BSA’s take the Product Owner’s summary of the business need (the “Description” in the Agile User Story) and translate that into something meaningful to the development team by talking with the folks performing the business task who have the need for the software / system solution. Without this expansion on the “As a user, I need a system to automate my process” the Developer and Product Owner are too far apart in terms of understanding the need. The BSA role in agile, in my opinion, is best served continuing to provide that analysis that they always have – working with the Product Owner to help explain what the business is asking for and helping to explain to the development team what kind of system changes would elicit that output. I think in agile, more than ever before, the analyst plays a key and indispensable role.

    1. Thank you Susan for your perspective. If this pattern works for you that is great. My experience is that the business analyst that works as the go-between as you have described decreases efficiency.

      Thanks, Anthony

  10. Hello, it was a very interesting article, and I will re-read it multiple times, because it provides great insights. I started programming around 27 years ago – as a kid – went to the university, and joined a big international company. Since then I was employed by multiple companies, around 2 years ago I moved to a business analyst/system analyst role, so here are my insights.

    One thing I learned that analysis is a very, probably the most important part. I know that according to SCRUM the developers need to be able to do basically anything, and it worked pretty nicely in the group I spent the most time, with 4 senior (understand 20-30 years of experience) developers. It was great because we talked to the customer, understood the topic, and made things work. That was brilliant. Later I got my own team in new project consisting of multiple teams as a team lead, but the group consisted of junior and medior developers. The idea of doing analysis together just did not work anymore. People either did not understood what we had to talk about and they wanted to just write code. Since multiple teams had to communicate and depended on each other I started to do something else: I started to gather information: requirements, dependencies, screen designs, talked to business and discussed possible directions etc. The result was shocking: when the sprint started we had every information to make estimations, tasks, and it was clear for everyone what needs to be done. The developers were not frustrated any more because everything was organized nicely and they knew what they had to do. The result was great but required lots of preparation and a proactive approach, which as I learned later is not as common as I thought it was.

    In my current job we are doing something even more interesting: we “implemented” an agile way of business analysis. When a new requirement is present we talk it through with the PO-s. They mostly have an idea, and we need to challenge those ideas and find solutions to provide a solution. What we do is we use modeling techniques (we use SysML) to come to a common understanding. First we create a domain model with the necessary concepts, then we challenge it with the various requirements and use cases. When it looks good (it is normally 3-4 1.5 hour sessions) we ask developers and experts (security, compliance, ux, etc.) who are fit to the task to check our concept. If everything is okay, we start modeling the solution (domain model, processes, etc.), which goes through a series of reviews (by other analysts, PO-s, and developers as well). We model in increments (we cut horizontally or/and vertically depending on the situation). When everything is done, tasks are being created and put in the pipeline. We are around 2 sprints before the developers so that we can continuously supply the with tasks.

    What I learned that strict SCRUM has it’s own requirements, and if those are not satisfied it will just cause struggle and unhappiness. Every organization needs to find its own way to create products, which fits the culture, business, and the resources at hand. It is a process which requires dedication, questioning, and continuous improvement.

  11. Hello,
    I wrote an article on the same topic with a very different view point and I also did research on this topic.
    The Scrum Guide DOES mention BAs, and as part of the team, please see my article for the quotes to explain, as the Scrum Guide does define the development team and agile team as a whole as ALL the roles/skills needed to do the work including BAs (and other roles listed). BAs and POs also have about a 90% skill overlap and great BAs make great POs!

    My Blog on this

    My research project on this


    1. Hi Angela, thanks for commenting on the blog and sharing your writing. I think we agree on a couple of points:
      – The BA role is mentioned in the Scrum Guide with advice to not create a sub-team of specialists
      – The BA role has many of the same skills as the Product Owner

      I am not among those that say that the BA role is no longer needed when organizations move to Scrum. My point was that the BA needs to act as one of the 3 Scrum roles. If they are on the Development team, then they need to collectively own the delivery of the sprint goal. In my experience, the BAs do NOT want to take ownership for delivering the tasks in the sprint backlog. They want to focus soley on BA tasks.

      I think you are being a bit cheeky when you say “I can’t find anything in the Scrum Guide that says there is no BA role or BAs is no longer needed.” Right or wrong, the Scrum Guide is pretty clear that there are 3 and only 3 roles on the Scrum Team and BA is not one of them.
      Further, the Scrum Guide describes the Development Team as self-organizing and cross-functional. “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” Doesn’t this mean that the development team has business analysis “competencies”, but not a “role” for BAs? And that the BA doesn’t sit outside the development team, creating a dependency?

      Finally, I am not sure that I agree with your statement that “most BAs make great POs”. In most of the organizations I have worked with, the BA has limited authority and decision-making power. The Scrum Guide says that “For the Product Owner to succeed, the entire organization must respect his or her decisions.” Do YOU see BAs that are empowered and able to make decisions that stick?

      Thanks again for weighing in with your comments and sharing your article. I’m interested in hearing your responses to my questions above.


  12. Hi Anthony!
    I think we agree on most things and it all gets lost in the context and phrases that everyone is getting hung up on.
    I also think that the term “role” is loaded! Everyone gets caught up in roles and titles, rather than skills. And, furthermore the term “development team” is misunderstood by so many that is only consists of “developers”, where many traditionally think of as engineer/programming skill set rather than ALL THE SKILLS needed to get the work done to deliver software.

    Simply put, BAs are feeling very frustrated and unappreciated by agilists that claim the “BA role” is no longer needed is agile. It translates as “your skills are not needed/you are not needed”, and that is not the intention nor the truth. BA skills ARE needed on agile teams, and for a Scrum team that can be on the development team or on product ownership. In other agile approaches it may not matter what you call it. “3 roles on a Scrum team” is simply taken too literally by many and misunderstood as to what that really means. The Scrum guide is very clear that these “roles” are not literal title translation roles and are about SKILLS, not the traditional meaning of roles/titles that most associate the term with.

    I mentioned that 90% skills overlap in the PO and BA skillset that makes many great BAs become great POs, and the 10% missing in the skill set is the decision making empowerment and often the “managing up” that comes with that. Otherwise the skill sets are very similar and many organizations can benefit from using BAs in PO type roles, partnering with the PO is my favorite model, where the PO role is SO big on some teams an effective PO/BA team can be amazing. I think it is up to organizations and agile teams to help the BA step into the empowerment of that needed decision making, especially in corporate cultures where the BA has never been given it, and the BA also has to step into the role and be confident in how their skills translate. Which comes full circle, BAs are struggling with this confidence when all they here is “there is no role for BAs in agile”.

    I hope this helps bring this all together?


  13. Nice article. Eliminating specialist roles is a key part of moving to Scrum. The specialist roles create bottlenecks and inefficiencies.

    1. If eliminating specialist roles is a good thing then the next people with cancer should forget about seeing an oncologist and just see their family physician. smh

  14. Anthony, having been a developer for more years that you have been on the planet, I can tell you confidently that you are deluding yourself if you think you are going to get developers to become competent BAs. My undergraduate degree is in I.T. and I have served in every role from manager, developer and BA, etc. Developers typically like to program and are usually poor business analysts. The biggest failing of Agile dogma is the concept of abolishing the BA role. If a strategy is not developed keep a skilled BA as part of Agile Scrum then poor quality software will be the norm for Agile.

    1. Greg, thanks for taking the time to comment. And yes, I am probably deluding myself on this and many other topics.

      To be clear though, I am not suggesting that Developers are as good or competent at the BA activities as a specialist. But if they don’t understand the language of the business or the needs of the customer, they are probably not going to be a great developer. Without understanding context, doesn’t matter how good they are.

  15. If I’m reading these comments correctly a lot of BA’s seem to look at devs in the most stereotypical way. Narrow minded, a-social people who only want to produce code with the minimal amount of interaction. To think so lowly of your colleagues is kind of sad. And only BA’s have the super powers that can bridge the gap between the business and the software.. Really?

Leave a Reply

Your email address will not be published.

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

Get More Done Faster

Join 12,000 other Agile practitioners and leaders who receive our monthly Agile and Lean insights to help them achieve competitiveness, productivity and business agility. Go faster!