Business Analysts in Scrum

Posted on Tuesday 9th March 2010


This blog post explains the role of business analysts in Scrum.

88 Flares 88 Flares ×

Business analysts play an important role: They usually act as the link between the business units and IT, helping to discover the user needs and the solution to address them. In Scrum, there is no business analyst role. So what happens to the business analysts?

Option 1: Business Analyst Plays the Product Owner Role

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

I feel that this option is often a natural extension of the business analyst role. But it usually implies change: A business analyst turned product owner should now own the product on behalf of the company, and be empowered to decide what the product should look like and do, and when which functionality is released. The individual usually also has to learn new skills including leveraging product increments to understand what users need and how their needs can be best met, grooming the product backlog, and writing user stories.

Option 2: Business Analyst Works as a Team Member

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

Business analysts working as a team member often help their peers groom the product backlog. 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 pick up new skills, broaden your expertise, and be open to work in new areas.

Avoid the Proxy Product Owner Trap

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

Using a proxy product owner is not well suited for delivering new features: At a client of mine, the head of a business unit was asked to take on the product owner role for a new product. As he struggled to spend enough time with the team, 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. What followed was an increase in miscommunication, a slowdown in decision making, and a decrease in productivity and morale.

If, however, your objective is to maintain an existing product by delivering small, incremental releases, then you may want to continue working with your existing roles and consider employing a linear, Kanban-based process, as I explain in my post “Choosing the Right Lean and Agile Innovation Practices“.


Scrum is not bad news for business analysts, and the individuals still have a job to do. But just like other specialised roles, the work of a business analyst changes in Scrum. Analysts either play the product owner role or work on the team engaging in a broader range of activities.

You can find out more about business analysis in Scrum by attending my Certified Scrum Product Owner training course or my Mastering the Product Backlog training course.

30 comments on “Business Analysts in Scrum

  1. […] Business Analysts in Scrum « All Things Product Owner – Roman … […]

  2. […] the original here: Business Analysts in Scrum « All Things Product Owner – Roman … Share and […]

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

  4. technical writer…

    technical writer are important whether it costs money take care of or not. Supporting information is vital and so your post Business Analysts in Scrum ” All Things Product Owner – Roman … makes interesting reading. I hope many see it and take notice…

  5. […] owner mistakes Desirable characteristics of a product owner Product owner = product manager? Business analysts in Scrum This entry is filed under roles with the following tags: budget, grooming, product backlog, […]

  6. 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?

  7. […] longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. As Roman Pichler puts it: what’s left to do for business analysts in Scrum? I have seen business analysts working as team […]

  8. […] A project manger is then tasked with executing the project, and works with a business analyst, requirements engineer, or architect to analyse and refine the […]

  9. […] For software developed in-house, a project manager or business analyst may play the role. […]

  10. […] For instance, a business analyst who does most of the product backlog grooming work […]

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


  12. […] can’t the business analyst be part of the team ? ( Roman Pichler offers more information on this here […]

  13. 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?

  14. Ryan Hewitt says:

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


  15. 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?


  16. […] organizations is how the role of business analyst should integrate with our Agile teams. In 2010, Roman Pichler crafted a blog post with a few options and I’m sure there are many other opinions out […]

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

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


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


    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.

Leave a Reply

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

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>