Photo courtesy of Pexels

Business Analysts in Scrum

Published on 9th March 2010 Last Updated on: 9 May 2023

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. The new product owner often has to learn new skills to effectively play the role. This includes creating a valid product strategy, developing an actionable product roadmap, and aligning the stakeholders in addition to working with the development team and managing the product backlog. Consequently, the individual will usually benefit from developing the appropriate product management skills.

Business Analyst as Team Member

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

Business Analyst as Team Member

Business analysts working on team often help their peers refine the product backlog. But as backlog refinement should be a team effort, analysts working on the team will 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 below.

Business Analyst as Proxy Product Owner

Avoid using a proxy product owner—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 the individual struggled to effectively fill the role due to their other work commitments, the business analyst stood in as a proxy. While the analyst took care of the product backlog, the business unit head make the strategic product decisions and told the analyst which product features should be implemented. Unfortunately, this resulted in misalignment, a long-winded decision-making process, and poor morale.

Post a Comment or Ask a Question


  • Charan says:

    Hi Roman,

    I am new to this field, I recently joined as Business Analyst. My senior BSA started writing user stories and assigning it to me and working on those. I don’t know how to show result for the work I have done and how to complete my cards and do my analysis.


  • Tom S says:

    Hi Roman,

    I have recently taken a new Senior Business Systems Analyst role with an agile development team. I have over 25 years of BSA experience. Previous to my current role, I was a Product Owner/Technical Product owner for a different product and development team. I loved my job and was very successful at it. I worked hard with long hours but absolutely loved the work. Unfortunately, I had a life threatening medical issue and missed 15 months away from work in the hospital and recovering afterwards. Before I returned to work, the team and the product were moved to another part of the company after some restructuring. The senior management decided to assign their own product owner. So, when I returned to the company after my medical leave, they were trying to find a spot for me. It’s an excellent company; they stood by me through my illness and recovery.

    Here is where the difficult part is. I am struggling to become part of this new team. They have some dysfunctional issues they are trying to work though. They also have a new resource manager who is from an outside company. The Product Owner is technically savvy and is dedicated and available. The Scrum Master is an over achiever who actually performs more than one role. The development team and my resource manager have been giving me developer type work assignments such as extracting logic from examining the code. In addition, they are expecting me to automate the functional testing. I have struggled with these technical tasks because I haven’t done them before and there is no training other than 15-20 minutes to handoff the work. The application is basically a RESTful api provider to integrate some enterprise applications. It’s a very technical product with no UI’s.

    The Scrum Master and System Architect are also assigning me a lot of trivial, low-value add tasks (administrative assistant type tasks). For example, I had to call the help desk and waited in the queue for 3 hours waiting to find out all of the permissions and security groups that the developers belonged to. I had to do this effort because the developers wouldn’t answer my questions. The developers think that since I am not doing development work that I don’t belong there.

    The PO does not want to spend time with me and leaves me out of meetings and emails. So, I struggle to fully understand what’s going on. This is an overwhelming challenge for me. I’ve been in the position for 10 weeks. There are several problems, the main one being that my success needs their cooperation; their success does not need or depend on my role/contribution. In other words, my objectives and the rest of the team’s objectives don’t align.

    My management knows that I want to do Product Owner work but there aren’t opportunities in this company at the moment. I am doing the best that I can in my current situation and maintaining a positive attitude. In my professional network, I have heard of other business systems analysts being stuck in a similar situations. Many have moved away from BA/BSA roles into being a PO, Scrum Master or developer. What is your advice for my situation? Should I resume my PO career elsewhere? Should I stay and learn as much as I can about technical/developer work?

    Thank you!

    • Roman Pichler Roman Pichler says:

      Hi Tom,

      Thank you for sharing your context and question with me. It sounds like you are in a difficult situation. Based on what you have told me, it seems that you are currently a member of the development team. If that’s true, then you should not be assigned any work but choose tasks in the Daily Scrum in collaboration with the other team members.

      To improve the situation, I would suggest that you have meetings with the Scrum Master, product owner, and your line manager. It may be not be easy but try to understand the Scrum Master and product owner, practice active listening, and try to empathise with them. Then share your perspective and emotions. Additionally, consider addressing the issue in one of the next sprint retrospectives to decide together how you can improve the situation.

      If you have already done this or if these aren’t viable options, then try to change teams for now and reconsider your longer-term career prospect and future at the company. As a product owner, you will need in-depth technical skills only if you look after a technical product that is integrated into a larger offering. Otherwise, you are better off developing the specifc product management capabilities the role requires.

      Hope this helps and good luck!

  • Amanda says:

    Great blog!

    I wanted to get your feedback on the following situation. I just started a job as a BA for a company that’s never had a BA role but found it necessary to help the team. The devs and the project manager are so used to doing all the work the BA would be doing, the biggest example here is gathering requirements. The devs are totally capable of doing this but the goal is to get them coding more instead of doing things I could do. Any tips on how I should go about transitioning? Somethings I’m sure the development team has been used to for years! Change is not necessarily wanted by some developers but needed to help improve processes currently implemented. Also I’m only 3 years into my career as QA/BA/a little bit of development/Scrum Master. I got hired on for a pure BA role though, so it doesn’t help that I’m also new and still learning.

    Any feedback would be great! Thank you!

  • Simon says:

    Hi Roman,

    I love your site (thank you) – I am currently working with some BA’s in a Scrum environment. Whilst I understand that the efforts of backlog refinement are a team effort it is sometimes necessary for BA’s to work on other supporting items such as Compliance Docs – As this needs to be done would you include it in the Backlog and estimate accordingly or view it as a separate piece of work managed elsewhere?

    • Roman Pichler Roman Pichler says:

      Hi Simon,

      Thank you for sharing your question and feedback. I would suggest that achieving compliance, be it with internal standards or external ones like regulatory requirements, should be the responsibility of the entire development team. How the team carries out the related tasks is up to the group: It’s part of the team’s self-organisation. In other words, a business analyst who works on the team might carry out the compliance tasks just like a tester would typically carry out testing tasks.

      Does this help?

  • Clare Bonsall says:

    I manage a hybrid BA and project mgmt team currently and the technology organisation in house is moving to SCRUM. Product management feel they are product owners but are struggling with the requirements engineering aspect. There seems to be several options, we all become product managers, we create a BA role purely around reqs engineering and documenting. Possibly some testing element but QA are embedded in the scrum team and we are using BDD. Or that the BA function is made redundant. Thoughts on how best to proceed or what to explore?

    • Roman Pichler Roman Pichler says:

      Thank you for sharing your question Clare. To help you make the right choice, I’d like to draw your attention to the fact that requirements engineering changes when Scrum is introduced. It is a collaborative effort shared by the product owner and the development team. In other words, the dev team should actively contribute to discovering, describing, and refining product functionality. This seems to rule out the second option you mentioned.

      Additionally, when working on larger products, a single product owner is often not enough, and product ownership has to be shared amongst several people. A good model is to have one overall product owner and people who own product parts: feature and component owners. If that’s a model you decide to adapt, some of the BAs could work as feature owners. This may well require that the individuals acquire new skills and/or deepen existing ones: Working as a feature owner means working in product management.

      Does this help?

  • Fiammetta says:

    Hi Roman,

    Thanks for your blog post. I would like to get your feedback about this case: A platform-driven company that offers to its customers (both end users and brands for which it represents a technology partner) digital products and services created a tech governance function to facilitate the dialog and collaboration between Tech and Business. In the Tech stack there are “functional” analyst and Platform Owners, in the Business divisions there are Product Owners, scrum masters and devs while the Business Analysts have been included in the Governance structure to work along with program managers and enterprise architects.

    1) shall I assume Business Analyst are mainly in charge of product backlog refinement, showcases, UAT?
    2) should Platform Owners be considered as Technical product managers owning the vision, strategy and roadmap of their respective platforms/capabilities?
    3) what is the difference between functional and business analyst? Maybe the former is in charge of a specific set of capabilities and support the platform owners while the last is a sort of E2E product manager?

    • Roman Pichler says:

      Hi Fiammetta,

      Thank you for sharing your questions. Here are my answers:

      Ad 1: Product backlog refinement is a collaborative task in Scrum and should be carried out by the person in charge of the product together with the development team. As I mention in the article above, business analysts may be well suited to contribute to the backlog work, assuming they work on the dev team. But they would also be expected to take on other tasks to help reach the sprint goal.

      Ad 2: Yes, you can look at platform owners as technical product managers, even though there is a difference between a traditional product manager and a product owner, as I explain in the article “Product Manager vs. Product Owner“.

      Ad 3: I had to look up the role description of a functional analyst as it’s been a while since I last worked with such an analyst. Here is what I found: “A functional analyst is a type of business analyst who specializes in a specific technology, line of business, domain or industry.” In the context of software platforms, such an individual may be a good candidate for taking on the platform owner role, assuming she or he has the necessary technical knowledge.

      It might be helpful to consider that Scrum intentionally does not differentiate between different roles on the development team in order to encourage collaboration. No matter what the team members’ specialist skills are, what counts is jointly reaching the sprint goal and creating value together.

      Hope this helps!

  • Andy says:

    Hi Roman,

    I am a BA and have been involved in a GDPR project.

    Testers: (outsourced)
    I ended up writing test requirements for the testers, they originally only had happy path tests and about 30% of the tests I ended up putting in place. They had no negative tests
    The issue I found with the testers is they have no “Business Domain” knowledge, they were no finding basic business domain errors. I was checking the results of what the testers had passed.
    The testers can work their way through the functional screens, but can’t identify the “business domain” issues.

    Coders/Developers: (outsourced)
    This is another group that has no “business domain” knowledge. They had written code that did not align with the business domain process. They had followed the business requirements (user stories) and acceptance criteria, but without basic business domain knowledge, the processes once put together after they were built failed.
    The coders can write code but it is very basic, but again no business domain knowledge

    From seeing the same issue in a number of different companies and most of the teams.
    The conclusion I have come to is:
    1. Testers need to know their systems and the basic business domain
    2. Developers need to be very experienced to know how to create efficient and configurable functionality and also have basic business domain knowledge.

    Without that basic business domain knowledge, the Developers expect detailed specifications – which goes back to the Waterfall process.

    The company fired the last set of consultants (big 4) because the had the same issue.
    They have another one of the (big 4) and the same problem exists.

    Is it just we have ineffective developers and testers or do we go back to waterfall?

    • Roman Pichler Roman Pichler says:

      Hi Andy,

      Thanks for sharing your context and question. I agree with your observation that without some domain knowledge, it is hard for developers and testers to do a good job. The question im my mind is how do you help the individuals acquire the relevant knowledge? The traditional approach is to specify all known requirements ideally in such a way, that they can be directly implemented. The agile approach is to involve developers and testers in collaborative product backlog work and discover and describe functionality together, see my article “8 Tips for Collaborating with Development Teams“.

      If close collaboration is not feasible for you, then you don’t have to go back to a waterfall-based process. But you may want to select working with use cases or a similar technique that allows you to thoroughly describe the product’s functionality, please see my article “User Stories or Use Cases?” for more information. Hope this helps!

  • 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

    • Roman Pichler Roman Pichler says:

      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!

  • Manuel says:

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

  • 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!

  • 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.

    • Roman Pichler Roman Pichler says:

      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!

  • 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

  • Niko Zimmermann says:

    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

  • 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.

  • 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

    • Roman Pichler Roman Pichler says:

      Hi Max, Thanks or your feedback and question. I recommend that you consider assigning a product owner to each product. The business analysts may be well suited to take on the role but may equally benefit from strengthening their product management knowledge. You could ask them to take my product management test to determine the areas they should improve: Hope this helps.

  • 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.


    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.

  • 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 .

    • Roman Pichler Roman Pichler says:

      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.

        • Roman Pichler Roman Pichler says:

          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!

  • 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.


  • 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.

    • Roman Pichler Roman Pichler says:

      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.

  • 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?


    • Roman Pichler Roman Pichler says:

      Hi Arnie, I find it useful to create the user manual incrementally, from sprint to sprint. You may also want to include the manual in your definition of done.

  • Ryan Hewitt says:

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

    • Roman Pichler Roman Pichler says:

      Hi Ryan, Thanks for your comment. I am afraid we have to agree to disagree. The product owner role is strategic *and* tactical, as I explain here:

  • 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)?


    • Roman Pichler Roman Pichler says:

      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?

  • Fabrice Aimetti says:

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


  • 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.

    • Roman Pichler Roman Pichler says:

      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?

        • Roman Pichler Roman Pichler says:

          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.

  • 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.

Leave a Reply

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

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.