Business Analysts in Scrum

Roman Pichler

Written by Roman Pichler

on Tuesday 9th March 2010

Summary

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

110 Flares Filament.io 110 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“.

Summary

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.

Source: http://www.romanpichler.com/blog/business-analysts-in-scrum/

Tags related to this post

32 comments on “Business Analysts in Scrum

  1. Geoff Watts

    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.

  2. Ioannis

    Hello,

    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,
    Ioannis

    References:

    [1] Is the Business Analyst a Product Owner or Tester on Agile Projects?
    http://www.batimes.com/elizabeth-larson/is-the-business-analyst-a-product-owner-or-tester-on-agile-projects.html

    Extract:
    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
    http://www.scrumalliance.org/articles/149

    Extract:
    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)

    Extract:
    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

      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

        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

          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?

    • Roman Pichler

      Thanks for translating the post, Fabrice!

  3. Sadia Rubbani

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

    Regards,

    • Roman Pichler

      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: http://www.romanpichler.com/blog/the-single-product-owner/

      Does this help?

  4. Arnie

    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?

    Thanks.

    • Roman Pichler

      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.

  5. Kim

    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

      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.

  6. Bill Gladwin

    Roman,

    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 http://www.VirtualBusinessAnalyst.net and et me know what your thoughts are. I’m always looking for improvements.

    Bill

  7. Tim

    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

      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.

  8. NATALIA CAMARGO

    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.

    • Roman Pichler

      Thanks for your feedback Natalie. It’s great to hear that you like my posts.

  9. Allyson

    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.

    • Roman Pichler

      Hi Allyson, Have you thought about playing the product owner role? Based on your description of what you used to, so such as interviewing clients, prioritising features, and managing the stakeholders, this seems like a great fit. You can find out more about the product owner role here: http://www.romanpichler.com/blog/one-page-product-owner/

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=""> <s> <strike> <strong>

110 Flares Twitter 9 Facebook 1 Google+ 24 LinkedIn 76 Filament.io 110 Flares ×