The Yin and Yang of the Business Analyst and Product Owner Roles

Jacqueline Sanders-Blackman

Jacqueline Sanders-Blackman

The Yin and Yang of the Business Analyst and Product Owner Roles
Share
Share on facebook
Share on twitter
Share on linkedin

A couple of months ago, I wrote a blog post on how to inventory whether or not your team has an adequate agile analysis toolbox and is prepared to perform analysis at the appropriate level (Inventory Your Agile Analysis Toolbox). Since we know that the process of requirements gathering and analysis has to occur, I wanted to address which role or roles perform analysis in an agile environment, more specifically the BA and product owner role.

Not all project teams have a role that is dedicated to the adequate skills and techniques needed to effectively perform analysis. A team without a dedicated business analyst can work, as long as someone, or the team collectively, performs a role associated with doing the right level of analysis that will lead to delivering the right solution.

Product Owner Role = Business Analyst?

Some teams will utilize a product owner role to perform the role of the business analyst. The product owner in an agile environment is the person which, at a high level, is building the business case and then ensuring that the solution stays aligned with the product roadmap and business goals. The product owner is typically assigned to the project team and works with them on every aspect of the development of requirements, designing the solution, and testing to make sure the anticipated value is met. Ultimately the product owner wants to make sure the solution provides value to the customer and stays in line with the vision for the product. This role also leverages their knowledge of the product, the business, and the industry, as well as information gathered through direct customer contact. The team member in the product owner role is considered to be the representative for the customer, also known as the “voice of the customer.”

At first glance, you might think the product owner is synonymous to the business analyst. Or you might think the business analyst role is redundant on a project team that has someone in the product owner role.

However, in my experience, it’s rare to have individuals with both business and technical skill sets and experience. Having the skills and the bandwidth to do a thorough job of both is a challenge. And even with both skill sets, one person lacks the ability to be their own check and balance. It’s hard for someone to “ask themselves the right questions” and then to dissect their own answers to see if the answer was complete. If one individual is performing a dual role, it’s critical that the person understands that they may have conflicting goals and desired outcomes.

The Yin and Yang: Two Roles Working Together

Wikipedia defines the Chinese philosophy of yin and yang as “how opposite or contrary forces are actually complementary, interconnected, and interdependent in the natural world, and how they give rise to each other as they interrelate to one another.”

In successful environments, when there are two people playing the roles, they have an yin and yang mixture of skills, experiences, and techniques as well as some overlap in skills. The business analyst is a facilitator, an investigator, and a fact checker; they reconcile, coordinate information sharing, find gaps, and perform traceability and impact analysis. The business analyst actually can help free up the product owner to do things in addition to overseeing the project requirements. The product owner may have other tasks including meetings, running the business, personnel responsibilities, training, presentations, and general liaison activities with a large client base and leadership.

Is your team not ying-ing and yang-ing? Our Enterprise Agility solution can help!

The shared skills needed by the product owner and the business analyst include eliciting, analyzing, communicating, prioritization, stakeholder analysis and facilitating the requirements and priorities from their consumer. Although there is clearly a common thread of skills between the product owner role and business analyst role, there are some important distinctions.

 Product Owner RoleBusiness Analyst Role
Primary Activities
  • Represents or is from the business
  • Builds consensus of the user/business
  • Accountable to the Business Sponsor
  • Has content authority - owns what to build and what sequence
  • Very regularly in the room with the team
  • Conveys expectations
  • Accepts features & user stories
  • Coordinates Product Council
  • Locates, understands and defines stakeholder needs/styles of communication
  • Elaborates additional specifications, if necessary
  • Partners with the PO in communicating the product vision and making sure it's understood
  • Facilitates the conversation and negotiations between business and IT
  • Writes user stories and supporting artifacts
  • Participates in backlog refinement, grooming and prioritization
  • Enterprise and technical impact and gap analysis
  • Identify and close gaps in the acceptance and the input to the testing activities
Shared Activities
  • Define the problem area
  • Determine if the need is worth satisfying
  • Prioritization
  • Determine the best solution to satisfy it
  • Validate the need was satisfied
  • Decision making
  • Define the context
Shared Activities
High Level Skills
  • Subject matter expertise related to the people, processes, terms, definitions, and software
  • Strategic visioning
  • Analytical skills to ask the right questions, dissect, organize, translate and cross reference requirements
  • Prioritization methods
  • Progressive elaboration
  • Feature based road mapping
  • Effective user stories
  • Acceptance criteria definition
  • Elicitation techniques
  • Facilitation techniques
  • Communication styles and techniques
  • Negotiation
  • Reconciliation and traceability of missing details
  • Full coverage of the core components of software design

To help illustrate, consider the three aspects or buckets of analysis on most software related projects: subject matter expertise, software requirements, and design/solution implementation. A common scenario is when the product owner has subject matter knowledge versus the business analyst who has software requirements and design/solutioning experience. The two roles working together would ideally be on teams because the problems and solutions we tackle in today’s software and technology driven world are extremely complicated. These types of complex projects require the experienced viewpoint of the customer and business as well as the technical facets to develop the right solutions. Additionally, when the two roles work together, they help provide a check and balance as well as reduce requirements gaps. The business analyst can help ensure the right questions are asked, and the product owner can provide the answers and decisions needed by the project team.

Does that mean that every project team needs to have a product owner and a business analyst? No.

A Team Approach

Not only are there times when one person can play both roles, there are also times when members of the team with various titles can divide and share the roles.

Like most things we talk about around software development, every organization does things differently and the lines are often blurred as to who does what. There are blurred lines between what titles companies use and several different blended/hybrid definitions of roles. Product owners may be called product managers or business owners. The product owner may have the role of project sponsor and/or subject matter expert as well. More and more, it’s less and less about the titles. It’s about the skills and capabilities to create a high performing team.

For help assessing your team skill gaps, download our Business Analysis Proficiency Assessment.

The most important to understand is what tasks and responsibilities are generally associated with a particular role, and then determine the best way to make sure you have coverage of those skills on your team.

I’d also love any feedback – just let me know below in the comments!

All the best,

Jacqueline

More on Business Analysis

Join our #AlwaysLearning Community

About the Author

Jacqueline Sanders-Blackman

Jacqueline Sanders-Blackman

Jacqueline Sanders-Blackman is a Netmind Lead Expert and Senior Instructor who has provided training and mentoring throughout her career in the areas of business analysis, database administration, data analysis and process improvement. She possesses over 29 years' experience working on projects, using various methodologies and approaches including Agile, Extreme Programing, Waterfall, Object-oriented, UML, Six Sigma and CMMI. She has held roles of business analyst, project manager, program manager, tester, DBA, developer, process analyst. Her diverse background made Certified Scrum Master and Agile Coach a natural progression. She has spent the last 9 years building up her Agile experience and now has a track record of helping organizations through the challenging transition from waterfall to Agile practices. Jacqueline is a published author and contributor to industry related titles.  Jacqueline was recognized as a leader by Women in IT 2013, 2014 and BDPA 2015. Connect with Jacqueline on LinkedIn.

8 Responses

  1. In my situation, I am the BA and PO, a hybrid role. I ask the questions and make “recommendations.” At the end of the day, due to a thick political environment, I don’t have the control to make decisions. The final say comes from the clients, being the government.

    1. Thanks Tonya for your comment and for sharing. I do see the scenario you describe with our various clients and I very much agree that BA’s should make recommendations. The people that have to use, live with and are accountable for the end product should be the decision makers. The decision makers should leverage the recommendations from the BA as well as our counterparts (the other 2 members of the 3 Amigos) which include the Developer and Tester because together we are consultants and advisers to the decision-makers and/or (aka) Product Owners.

  2. Interesting read. I find my role as a BA is more about researching and modelling the business system or process that a product will serve to clarify stakeholders and requirements. This context provides input to the product owner, who then works with the BA to weight different stakeholders and requirements to generate a product roadmap. In short, the BA does the deep dive into the user context and the PM/PO uses this perspective to make informed decisions.

  3. How do the different roles work for facilitating ongoing support? Tier 1 type stuff, updates and patches, and regular application maintenance. Is the BA expected to stay in ‘the know’ or should the Product Owner initiate the BA when needed for such type of activities?

    1. Based on your question, it sounds like your development team does not turn the completed solution over to an operations or support team. Some companies have a whole separate team because it can be a challenge for a dev team to try to prioritize ‘new development’ versus ‘ongoing support’ in the same backlog. However, if your organization combines both, then those updates and patches should become stories (i.e. technical or tech debt stories) in the backlog and get prioritized by the Product Owner. When they get prioritized then they would be incorporated into the same grooming and refining process as other stories and that would usually be when the BA is engaged. Sometimes there are Urgent fixes but the Product Owner has to be very strict about defining and approving an urgent request. Otherwise, those urgent fixes will undermine the goals and commitments for the sprint.

      Please let us know if you have any follow up questions! Thanks for your comment.

      1. There is a problem with that: Scrum/Sprints are designed for development, not necessarily for (the emergencies) of Ops. What if you get hacked? You can’t handle that through a sprint. Or the system crashes for some reason.

        Wouldn’t it make more sense to switch to a sprint + some DevOps elements? You may then need less of a traditional Scrum Master and more of an Agile Coach.

        But I think in any case you’ll have to create a team that from the outset is geared towards both Development and Ops. The original question almost feels like Ops was an afterthought.

Leave a Reply

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

Almost done!

Please check your email to confirm your subscription.

Join our #AlwaysLearning Community

Onsite Training Request

Please provide the information below to help us to customize your solution. 

Contact Us

Netmind US
296 South Main Street, Suite 300
Alpharetta, GA 30009-1973
T. +1 (678) 366.1363
F. +1 (678) 366.1983

Office Hours:
Monday – Friday, 8:30-5:00EST

General Inquiries:
info@netmind.net

Sales Inquiries:
sales@netmind.net

Request Information