Business Analysts in Scrum

Published on 9th March 2010 2 min read

Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to discover the user needs and the solution to address them, and specify requirements. But in Scrum, there is no business analyst role. So what happens to the individuals?

Business Analyst as Product Owner

One option for business analysts is to take on the product owner role, as the following picture shows.

Business Analyst as Product Owner

I feel that this option is often a natural extension of the business analyst role. But it usually implies significant changes: The individual should now own the product on behalf of the company, make the appropriate product decisions, and be responsible for product success, as I discuss in more detail in The Agile Product Owner Responsibilities. The new product owner often has to learn new skills to effectively play the role. This may include creating a valid product strategy, developing an actionable product roadmap, and aligning the stakeholders—depending on the individuals current skill set. (You can test your know-how and identity gaps in your knowledge by taking my product management test.)

Business Analyst as Team Member

The second option for business analysts is to work as team members. This is option is depicted by the picture below.

Business Analyst as Team Member

Business analysts working on team often help their peers groom the product backlog. But as grooming is a team effort in Scrum, analysts working on the team take on additional responsibilities, for instance, working closely with the testers or the technical writer. As a business analyst on the team, you should hence expect to learn new skills and broaden your expertise.

Avoid the Proxy Product Owner Trap

Dealing half-heartedly with the role of business analysts in Scrum is a common mistake: Business analysts neither play the product owner role nor are they team members. Instead, they end up as proxy product owners, a go-between the real decision maker and the development team, as shown blow.

Business Analyst as Proxy Product Owner

Using a proxy product owner is best avoided—certainly as a permanent solution. Take the following example from one of my clients. The head of a business unit was asked to take on the product owner role for a new product. As he struggled to fill the role effectively, the business analyst stood in as a proxy. While the analyst did all the detailed grooming work, the business unit head decided about the product features and when which functionally was released. Unfortunately, this resulted in miscommunication, a long-winded decision-making process, and poor morale.

Learn More

Post a Comment or Ask a Question


  • Geoff Watts says:

    Hi Roman

    Nice article. The Product Owner is often a very challenging role for people to fill well and depending on that person’s skill set and experience, they will need support from various people in what we often refer to as the Product Owner team. Business analysis is a key part of this product owner team and also, as you rightly mention, within the development team.

    Just as the fact that there is no project manager role in Scrum doesn’t mean that projects don’t get managed; we may not have business analyst roles but we still need to do a lot of that work. The big difference as you pointed out well is that it will probably be done differently and possibly by more people than typical.

  • Ioannis says:


    After reading your post, as well as a few articles on the web (see references below), I came to the conlcusion that:
    1. During a Sprint, BAs work on analyzing requirements for the Sprint(s) to follow. They do however actively support the Scrum team in case of (business related) questions/misunderstandings, etc. in the current Sprint.
    2. Thus, BAs are not part of the core Scrum team, but rather part of the project team as a whole. This is because they are not working on the same context/goal within a Sprint. They are doing analysis for future Sprint(s), while the Scrum team works on items that have already been analyzed earlier (if not fully, at least at a great extent).
    3. BAs work in analyzing requirements for future Sprint(s) is facilitated by the so called “backlog grooming cycles” that take place in parallel to the “Sprint cycles”.

    Can you please share with me your thoughts on the above points?

    Thank you in advance,


    [1] Is the Business Analyst a Product Owner or Tester on Agile Projects?

    So how can BA do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks?
    By ensuring requirements are defined completely and correctly before each sprint begins.
    The BA can work with the product owner and other business and technical SMEs (Subject Matter Experts) as the delivery team completes each sprint.
    However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.

    [2] Requirement analysis and Design flow in Scrum

    In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).
    Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review
    Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done

    [3] Business Analysis in Scrum
    (see “The Agile Extension to the BABOK Guide”, IIBA, November 2011; paragraph 2.1.4 on pages 17-18)

    Scrum does not address business analysis activities in detail and many of these activities occur as implicit steps in the scrum framework.
    The building and maintenance of the product backlog is a significant business analysis activity that falls explicitly outside the scope of the scrum framework (although other methodologies have addressed this). The backlog is built through a combination of enterprise analysis work (identifying gaps and new capabilities required to accomplish organizational goals, and defining their value to the organization) and solution assessment and validation (identifying ways in which the existing solution can be enhanced to better deliver business value).
    Within a sprint, business analysis activities focus on defining the requirements for the backlog items being worked on and the acceptance criteria for those items. This method is frequently referred to as just‐in‐time requirements gathering; developing only what is required for the current sprint and only done to the level of detail required to enable the team to build the product and acceptance criteria. In traditional methods, requirements documentation is frequently used as the documentation for the solution. In Scrum, as in most other agile methods, documentation is created after the product is built to capture the team’s knowledge, not define an expected or desired outcome. Most frequently the backlog documentation created during each sprint serves as sufficient documentation for the project.

    • Dear Ioannis,

      Business analysis activities still take place in Scrum. But there is a significant change in how requirements are discovered and described: First, it is now a team effort, and no longer the job of a specialist. Second, ideas for new functionality are uncovered by gathering and analysing user feedback on product increments. The development team should work on the product backlog together with the product owner, for instance, in a product backlog grooming workshop.

      As a consequence, the job of a business analyst in Scrum changes: The individual either plays the product owner role or becomes a team member. In both cases, the BA takes on new responsibilities. As a team member, the individual is likely to help with testing and documentation or with architecture and development work – depending on his or her skills.

      • Dillon Weyer says:

        I often find explaining the function of a BA in a new Scrum team one of the most challenging. In one team I worked with, they were adamant to run a separate BA team sprint to gather the requirements for the following dev sprint. The challenge, not being a BA myself, is getting the BA’s to find the balance of finding out just enough info vs writing a full specification document.

        With the team that wanted the BA’s to run a separate sprint, I encouraged them to rather be part of a single team. Their argument was that they would still be gathering requirements ahead of time, so why not make it visible and part of a sprint? I wasn’t sure how to answer that question. Any ideas?

        • Hi Dillon,

          Thanks for asking the question. Two things might help you: First of all, make sure that you have the prerequisites to start a Scrum project in place. It’s particularly important to know who the customers and users are, why they would buy and use the product, and what makes the product stand out. See my post The Product Owner’s Checklist for the First Sprint for more details.

          Second, ensure that you have an effective grooming process in place to prep the next sprint. A collaborative workshop that involves the entire team, analyses the feedback and data on the latest product increment, and applies the new insights to the product backlog can be a great way to establish the process. Please see my post Grooming the Product Backlog for more information.

          Does this help?

      • Neeraj k bhatnagar says:

        Your comments helped me a lot to understand role of BA/QA.

  • Hello Roman,
    It’s a real pleasure to read your great posts… and to translate them into french :


  • Sadia Rubbani says:

    Hello Roman,

    I have following questions for you:

    Let’s suppose I am working as Requirement Engineer in a company, company in a transition phase towards adapting Scrum.

    Q1. Where will I place myself in Scrum environment?

    Q2. What equivalent role scrum offer?

    Scrum suggest multiple roles under the umbraella of ‘Product Owner’, and for complext environement number of product owner under chief product owner.

    Q3. Is there any scenario exist where Scrum delegate some job responsibilities of Product Owner to other roles? (Here, I specifically asking that any other role who can drive the user stories, backlog items from Product Owner vision document)?


    • Hi Sadia,

      I suggest that the choices for a requirements engineer in a Scrum context are the same as for a product owner. I also recommend you make sure that the product ownership resides within the Scrum team – the product owner, ScrumMaster, and development team – even if some of the product owner responsibilities are distributed. You may find my post on single product ownership in Scrum useful:

      Does this help?

  • Ryan Hewitt says:

    Very interesting article 🙂 I like to think of the BA as more tactical than the Product Owner who is strategic:

  • Arnie says:

    I think a BA can play the role of the Scrum Master, leaving the PO role to the Project Manager, and the team members to the dev team.

    Im thinking that this is the best case because just like Scrum Masters, BAs work in between the client and the dev team, trying to get what are the requirements from the client, and taking into consideration whether the requirement is something that can be developed.

    I have a question though. Where do you put the part where the user manual has to be created?


  • Kim says:

    I have been a BA for a long time, I think since before the title existed, and am on my first Agile project. So far, I see my optimal role as partnering with the product manager. My skill set involves going beyond what someone thinks they need to address potential business process re-engineering as well as to bring an “outsider looking in” perspective to the conversation. So, we probably don’t have a disagreement but my main value does seem to be in the backlog grooming arena. My role during a sprint, at least in my current situation, is more of a facilitator – I’m not taking on the product manager’s role but partnering with them to make sure we get what we need. I will say, though, that I am struggling with this a bit and still trying to find a way to add value.

    • Hi Kim,

      Thanks for sharing your experience. Sounds like the the way you split the work between the product owner and you works on your project, and that’s great. Maybe there is an opportunity in one of the retrospectives to reflect on your product ownership practice, and to see if there are any improvements you can make.

  • Bill Gladwin says:


    I’ve created a different approach. The Virtual Business Analyst. I’ve experienced with some clients they do not even have a true Business Analyst at their business. What I’ve created from talking with multiple directors, managers, clients and peers, a continuous link between departments that communicate with each other in a corporation. A tedious task but I feel it will be very valuable to most any corporation. Please check out my site and et me know what your thoughts are. I’m always looking for improvements.


  • Tim says:

    Despite all the creative ways folks are coming up with a purpose for the BA, people have to understand the feeling of suddenly having your skills farmed out to other peope and then telling you that you dont really have a role.
    You feel exposed as adding no value. No fuzzy statements and hopes of Agile purists are going to change the fact that your involvement just isnt goind to feel fulfilling on an Agile project unless they make room for your abilities..
    So it really depends on how ridiculously pure your Agile project is going to be.
    The premise of Agile as pointed out early on was, in part, to elminate te role of the Analyst, essentially by distributing out the central part of their skills; facillitaion to Scrummaster, Customer face to face distributed to the developers,
    In my last employment, the BA role wasnt part of SCRUm and when time came to cut back on staff, guess who looked like no valu add and was the 1st group to go, yep, the BA group.
    So lets be honest about te concerns of BA’s and admit that not evry Agile project will use them and that some may see it as a means of getting rid of the BA’s.
    You can blow it off as an evolutionalry thing, but its causing a lot of us to think about giving it up as a career, because it seems like a dead end career to me. Expecially when I am to dumb down my analysis on a 5×7 Card written in Crayon.

    Sad to say, I have seen this movie before .

    • Hi Tim, Thanks for your comment. I am sorry to hear that you have found that working with agile practices was used to lay off business analysts. While the role of a dedicated BA may not be required on a Scrum team, the business analysis skills certainly are. Applying agile practices and Scrum is not about getting rid of people. It is about creating more value and better products with the existing workforce.

    • Scrimmers says:

      In my opinion much of the fear I read here from BA’s comes from needs being focused on the self, and not on the team.

      This is fundamentally how teams work, you put the team and the teams goal first.
      Analysis skills are useful to a team, but trying to ‘own’ or ‘control’ a part of the creative process through function or role results in sub optimal teamwork (“I did my bit..”. ).

      There are those of us old enough to remember a time when there were no business analysts or testers. The roles were created by a management desire to ‘optimise’ the time developers spent writing code. A sub optimal behaviour in my opinion.

      Be a team player, leverage your skill, stop focusing on ‘me’, stop focusing on ‘role’.

      • Kenneth Loh says:

        Scrimmers, I would like to upvote your comment. Unforturnately, there is no such button here in this page.

        I find most times when a team member does not know his/her worth in the team, I normally look at the Scrum Master (or Agile Coach if it is other types of Agile team rather than Scrum). It is his role to ensure that members know their roles in the Agile team and how each of them contribute to their collective success that each of them will be able to reap.

        • Thanks for your comment and feature request Kenneth. There are different factors at play here in my mind: One is the question of how the Business Analyst role fits into Scrum, and particularly, to which extent it overlaps with the product owner role. The other is about teamwork and the role of the ScrumMaster. My focus in the article is on the former; I have shared my thoughts on the ScrumMaster role in “Every Great Product Owner Needs a Great ScrumMaster“. Hope this helps!


    Great article. I am a Business analyst and have been in the role of SCRUM Master and proxy PO, the last one usually ending in low speed in decision making and affecting team morale, as you said.
    Right now I am trying to move to a Product Owner role that would fit better with my business analyst skills.
    Thanks, I love all your articles.

  • Allyson says:

    Article and posts raise good points.

    I agree with Tim and will add to it.

    The main issue I see is that if you are a BA or tech writer on a Scrum team, there is not only no defined role, but also no clear path for career advancement unless you move laterally to a new business column or area that might provide it.

    You don’t have ownership of the success or failure of anything, since everyone contributes to it. The only one who gets any credit is the Product Manager, who usually is not a good Product Manager anyway and whose butt Engineering has to save half the time.

    You are just a nameless faceless technical factory worker “supporting” other people’s success.

    In addition, after a while (for me, it was a very short while!), it can become really boring, doing bits of piecework that are too complicated for anyone else on the team.

    Before working in an Agile shop, I used to interview clients, facilitate stakeholder meetings, resolve conflict, prioritize features, draft the body of the requirements, create wireframes (aka design part of the UX), be deeply involved in testing and have to signoff on readiness, play a large role with implementation, etc.

    And now there is “no defined role” for me? Who is doing all my work.

    Oh wait, I forgot, now our product only has to be “just good enough”, so, mostly no one is doing it, but they’re doing it fast.

    That is why I got OUT of Agile shops and back into iterative and Waterfall shops that use some Scrum on the backend.

    In this meantime I am taking courses for a new career. Of, to put it a different way:

    “As a Business Analyst, I want to take courses so that I can get the heck out of Agile development and have an actual career.

  • Max says:

    Hi Roman,
    very nice article.

    I’ve a more complicated scenario to address: my dev team is big enough to serve our two internal “customers” (demand channels) by splitting in two separate Scrum teams, and this is the path I’m trying to explore with the team.
    Each demand channel “owns” a family of software product for a specific target customer type. Because of this each demand channel is composed of three/four BAs.
    Let’s assume that one of them become the PO, what about the other BAs?
    What do you think about having them as team members?
    What other options do we have having fixed that we want to transition to scrum?

    Thanks for your reply

  • Jigar Chaudhari says:

    Hi Roman
    Wonderful article and I agree with you, as Business analyst can play a composite role in the scrum.
    Additionally, Scrum provides more opportunity to business analyst to play different role and help organization in more way i.e.
    Scrum master, Product owner and develop your leadership skill in it compare it with waterfall model. In Scrum BA are not just only developing the feature definition documents or functional definition documents but he can do more than that.

    As per my knowledge, I can think of below way Business analyst can help origination in scrum
    (1) Organizing the project inception and brainstorming session between all the project stakeholders in starting of the project.
    (2) Creating features based on project inception output and dividing into the User story.
    (3) Facilitating the scrum ceremony(sprint planning, daily stand-up, sprint review, sprint retrospective, and backlog grooming) in team
    (4) Designing the user story and adding wireframes and acceptance criteria in it.
    (5) Working with product owner (PO) for user story priority and reprioritize based on PO decision.
    (6) Removing impediments raised in daily stand up for the team
    (7) Working with developer and tester for the three-way handshake of user story before and after completing the user story making sure all are in the same page for business requirements.

    Scrum is ultimately helping business for fast-track development of the shippable product.

  • Hi Roman, we have a BA on the team and as the Scrum Master I worried whether we need her.
    Additionally we have a fully equiped Produt Owner and a skilled Team. So I thought the BA was useless. After reading your article I know, she is not .. She exactly do what the BA in the team can do. According your description, … groom the backlog and help the QA-Team (not Scrum, another stage) to understand testcases … Thanks Niko

  • Priya Kumari says:

    Hi Roman

    I am learning about B.A and its role. Can you please help me with the clarification on proxy product owner role and drawback

  • Gianpaolo says:

    Thank you for this interesting post. I work in a scrum team with developers and BA and I’m not clear on how to handle different skills in scrum teams. BA work mostly on solution design, documentation and testing, but they don’t do code. This makes the team not really cross functional, hence we often have difficulties when trying to estimate the story points to commit for the coming sprint, calculate/ predict velocity and release plans.
    Should we have in this case BA out of the scrum team and consider this as a dependency? On the other side, solution design, documentation and testing should be part of the definition of done.

    • Thank you for the feedback and sharing your question Gianpaolo. The best advice I can give you is to discuss the issue in the next sprint retrospective and determine the right improvement measures. Additionally, you may want to raise the issue to your Scrum Master–assuming that you are the product owner, as helping the team effectively collaborate and manage their work is the Scrum Master’s responsibility.

      Having said that, I would recommend keeping the business analyst on the team and broaden people’s skill set. I find that pairing people is a great way to help individuals collaborate and acquire new skills. This way, the developers on the team could learn about, say, solution design, by working with the business analyst; and the BA could become familiar with writing code by sitting with a developer. Additionally, you may want to give the individuals the opportunity to attend training courses and / or carry out self-study to accelerate the learning. These measures may reduce the team’s velocity in short run, but it should increase productivity and teamwork in the long run.

      Hope this helps!

  • Geoff Goodhew says:

    Thanks for this article – this is still a hot topic!! And one that’s far from resolved.

    One of the defining characteristics of “business analyst” job is the breadth of scope for business analyst ranging from the highly technical to the customer facing or process oriented. That means that a business analyst can fit sensibly all three roles in Scrum. You’ve covered team member and product owner, but, equally, I think some BAs have all the skills of a good scrum master. In particular, a focus on things like communication, facilitation, process improvement, and introducing enabling tools and practices.

    This is also part of the trap – the idea of a BA as a proxy product owner is one; but equally they can be the proxy scrum master. And the reverse is true: when I’ve worked as a scrum master, I’ve had to resist being too actively involved in backlog refinement; similarly, the product owner needs to know when to leave the fleshing out of user stories to the team.

    This is more a statement than a question, but it would be good to get your views!

  • Manuel says:

    Very useful article. I am now approaching this career and I really found your opinion useful.

  • Muhammad Al-Subaiee says:

    Many thanks for this article.
    please answer my following question:
    Suppose that we have an IT company A, and a customer company B that want from company A to develop a system for them (i.e. for company B).
    Now we need a person that recognizes the details of the requirements that company B needs.
    And as I know that the person that recognizes the details of the requirements is the Product Owner.
    My question is: from which company the Product Owner will be?
    Will he be from A or B?
    If from A: how can he recognize the details of the requirements of another company?
    If from B: should he be a system analyst to make use cases?
    REALLY I need the answers.
    Best wishes

    • Thanks for sharing your question Muhammad. If it’s a bespoke, custom product, then my preference would be to have company B fill the product owner role. Otherwise, the product owner should come from company A. Please see my article “Two Common Ways to Apply the Product Owner Role” for more information.

      Additionally, I’d like to remind you that discovering and describing requirements is a collaborative responsibility in Scrum, which should be shared between product owner and development team. Unlike in traditional processes, there is no specialist like a business analyst who is dedicated to this task. Consequently, the team members will have to acquire some knowledge about the market (users, customers, competitors).

      Hope this helps!

10 Trackbacks

    Warning: call_user_func() expects parameter 1 to be a valid callback, function 'blankslate_custom_pings' not found or invalid function name in /nas/content/live/romanpichler/wp-includes/class-walker-comment.php on line 179

Leave a Reply

Your email address will not be published. Required fields are marked *