fbpx

Debates about the Business Analyst (BA) role in agile are getting more frequent and more intense. Many organization leaders are even considering eliminating the BA role. These debates are usually sparked by a Scrum training class or an agile coach who is telling the organization that BAs are no longer needed in agile, claiming the Scrum Guide is the source of this idea that BAs are no longer needed.

The Truth About the Agile BA Role

As an agile coach, agile trainer and an advocate for the value of great analysis on teams, I am deeply disturbed by how often I hear there is no role for the BA in agile. This incorrect interpretation of the Scrum Guide is leading organizations down a path that will derail their agile transformation and limit their ability to deliver valuable solutions to their customers. Don’t let this false interpretation of the Scrum Guide disrupt your organization. Consider the following information about the BA role and the Scrum Guide. I can’t find anything in the Scrum Guide that says there is no BA role or BAs is no longer needed.

https://www.scrumguides.org/scrum-guide.html This idea is a common interpretation of the Scrum Guides contents and it is misguided. First, I will take a stance that there is no role for the following on an agile team: There is no role for requirement note-takers and there is no role for specification writers on an agile team. If you think that this is the BA role, please learn more about the industry-standard definition of the BA role from one of these sources:

Six Ways the Scrum Guide Supports Business Analysis

Looking at key pieces in the Scrum Guide will help us understand where the BA fits in.

  1. “Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis.” Ah….business analysis IS actually mentioned in the Scrum Guide as something IS needed, just like architecture, testing, and operations are needed. However, this emphasizes that sub-teams of these competencies are not helpful on a team. Keep the team small, with all the needed skills, and collaborate to get work done. It doesn’t matter what the title is, or if a single team member (or many) provide these skills to the team; they are needed to build successful products. The key here is that everyone works together, not sub-teams handing off to one another.  (Source in Scrum Guide: Under subtitle “The Development Team”)
  2. “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional.” and “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” The “Development Team” does not exclusively mean a “software programming” team, nor developing the code. It’s about developing a valuable increment that the team can get end-user feedback on. A cross-functional team means many roles, skills, and competencies. This may include a BA or other analysis skills.  (Source in Scrum Guide: Under Subtitle “The Scrum Team”)
  3. “‘Develop’ and development” are used in the Scrum Guide, they refer to complex work.” In the Scrum Guide, there is mention that this can refer to any complex work including product development, research, and product enhancements. This does not mean software programming exclusively. And if you are a software programming team, this is not just referring to the software developers—it is all of the people needed to complete the development. (Source in Scrum Guide: Under Subtitle “Uses of Scrum”)
  4. “The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.” This does not say, engineers and programmers. The intention is a cross-functional team with a variety of professionals who have all of the skills needed to deliver increments of work. (Source in Scrum Guide: Under subtitle “The Development Team”)
  5. “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person.” The Scrum Guide does not recognize titles, not even the “Developer” title. So, let’s not get hung up on titles that the “Development Team” should or should not have. It’s not about developers and engineers; it’s about a team that has all of the skills needed to deliver work. Scrum Master and Product Owner (PO) are also roles, not titles. It’s important to reflect on how your experience and organization may confuse roles and titles or define roles and skills based on titles that are unique to an organization, yet use the same words that the industry uses as a role. (Source in Scrum Guide: Under subtitle “The Development Team”)
  6. “Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”BAs may have specialized skills that the team needs, but they are measured with the team on progress as a team, not on individual deliverables. (Source in Scrum Guide: Under subtitle “The Development Team”)

BA and PO Role Differentiators

I believe that the product owner role description in the Scrum Guide most closely resembles what BAs (by the industry definition) do. The main difference is the decision-making authority, and it is a BIG difference. It’s a difference that expands into many of the team decisions, guidance, leadership, and impacts the very details of what the team works on. BA roles tend to be more detail-oriented yet within the scope of the PO vision of the product and customer experience. There are a lot of skills that the PO role needs and that a BA can contribute as well. It’s important that teams tightly collaborate on what skills each person brings to the team in playing each role and how they all work together towards a common goal. This begs the question: Is the BA a PO, a collaborator with the PO, or are they on the Development Team? I hear this question frequently. My take on this and how I interpret the Scrum Guide is that the BA can be any or all of these. BAs can be the PO if they have decision-making authority. If they do not, they can certainly partner with the PO and add value helping fulfill the PO role. The Scrum Guide does discuss that the PO is accountable for the work, but doesn’t have to be the person doing all of the work, and this is where the BA can be a great partner with the PO on the team.

business analysis product owner agile transformation teams

I have created a PO/BA Collaboration Model https://www.ba-squared.com/resources/agile-po-ba-collaboration-model/ as a starting place for teams to discuss the skills and activities these roles may partner on as part of the team. In many organizations, the projects are complex, and the PO has other responsibilities outside of how the Scrum Guide may define the PO role, so having a BA to help support the PO role works well. The BA may also be part of the development team helping get the work of the PO role done. Under the product owner subtitle section of the Scrum Guide, after listing the responsibilities of the PO, the Scrum Guide states The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.” We all can interpret the Scrum Guide how we would like and I am sure there are some that agree and disagree with my interpretation. I hesitate to quote partial pieces of the Scrum Guide, but I resist even more hearing “The Scrum Guide says there is no role for a BA.”  That is simply not true.  If you are hearing this within your organization, team, or elsewhere, please share this article and clear the air!

The Road to Hell is Paved in Good Intentions

My belief is that the authors of the Scrum Guide intended it to be a framework that is flexible for organizations of all sizes that use a variety of titles with unique job descriptions. As a result, this is the most generic way for the authors to write it while getting the context and agile values across. Every team forms around the work, and the work can vary significantly! Therefore, the skills needed for each team, roles, and titles will vary as well. It’s a huge mistake for organizations to translate the Scrum Guide literally when thinking about the Scrum roles as team member job titles. This literal approach is a direct conflict with the agile values established by the authors of the Scrum Guide and Agile Manifesto. It’s great to see so many adopting agile practices and as long as teams focus on the skills needed to get the work done and are not constrained by titles, some really great progress towards better products, speed to market, quality, and team morale are possible!

Delivering the Datastate of agile analysis 2019 business analysis report

I am so passionate about this that in 2019, I kicked off a first-of-its-kind research project. I gathered data from hundreds of agile teams to discover how teams use analysis skills and BAs. Additionally, I wanted to understand what analysis activities and techniques are used by successful agile teams. The results and the full report of this research can be downloaded here: http://www.ba-squared.com/report/.

By Angela Wick, CBAP, PMP, PBA, ICP-ACC, ICP-BVA

Connect and Follow Me on LinkedIn

What are your thoughts? Head over to LinkedIn to comment and further the discussion.

I want to thank those that provided feedback on this blog, especially the thoughtful feedback from Dave West at Scrum.org.