In some organizations, the role of the Business Analyst is often confused with that of the Product Owner. Although they may be performed by the same person, they view the same product from different perspectives.
If you ask around, you will probably get as many opinions as there are people willing to express them. To complicate matters further, there is no widely-accepted definition for the Business Analyst’s in the agile community.
Without trying to muddy the waters, it’s about time we came to a useful and concrete definition! So here’s a proposal:
The Product Owner orders the backlog to maximize the value of the product resulting from the Scrum Team’s work. The Business Analyst helps to understand customers’ needs by asking eliciting questions and translating the answers into well-formulated backlog items.
Does that mean that the Product Owner doesn’t create, write, or edit any backlog items themselves?
By all means, no.
A Product Owner who, for one reason or another, doesn’t want to touch their backlog is like a mason who doesn’t want to lift bricks. In other words, their attitude toward their role and work is dysfunctional.
However, on complex projects where a single user story requires its author to conduct several customer interviews and/or read through a pile of documentation, the Product Owner alone may not have the time, the attention span, and/or the domain knowledge to get things done.
That’s usually when the need for—and the value of—an experienced Business Analyst who can elicit, interpret, and systematize the customer’s needs or the industry’s requirements becomes apparent to the Scrum Team and to the organization that sponsors it.
When it comes to defining what a Business Analyst on an agile project does, I have yet to come to a better definition than that of Kent J. McDonald as published by the Agile Alliance.
“A Business Analyst,” McDonald writes, “supports a product owner by helping them analyze the business domain, stocking the product backlog, and grooming the product backlog.”
He goes on to elaborate that a Business Analyst doesn’t always have decision-making rights the way that the Product Owner does, but they can nevertheless become an indispensable member of the Scrum Team “by supplementing a product owner’s lack of time or business analysis skill sets.”
This subtle difference is critical to understand for anyone working in or with an agile team. The fact that a Product Owner is decisive does not make them analytical per se.
On high-risk projects, where the product is mission-critical or the industry is tightly-regulated, having a Business Analyst on the product to act as a sparring partner for the Product Owner and negate their blind spots may be non-negotiable.
The Product Owner’s Role
The Product Owner is there to make choices that make the Scrum Team’s work—and the resulting product—increasingly more valuable to customers.
These decisions are reflected in the contents and order of items on the product backlog. Ideally, these decisions are informed by both the customer’s (outside-in) and the team’s (inside-out) feedback.
Though the Product Owner has accountability over the outcomes of the work, he or she is in no way hierarchically above the Developers on the Scrum Team.
Just like a Scrum Team without a Product Owner wouldn’t be able to systematically agree on what to build, a Product Owner without a Scrum Team would end up with a vision for a product without anyone who is capable of building it sustainably.
The quality of those decisions becomes apparent over time.
When the quality is high, it manifests itself as high customer satisfaction and solid engagement among the members of the Scrum Team.
When it is poor, customers lose faith in the product, and the Developers on the team lose morale.
The Business Analyst’s Role
The Business Analyst is there to provide clarity and improve the Scrum Team’s understanding of the customer’s needs.
That clarity is reflected in the substance and the form of the items on the product backlog. He or she is the analytical counterpart of the Product Owner who can ask the right questions and find the best words (or visuals) for capturing the answers.
The Business Analyst is in no way superior or inferior to the Product Owner. As far as the Scrum Guide is concerned, they are considered a Developer on the team as their work directly contributes to the development (to read: evolution) of the product.
Like that of the Product Owner, the quality of the Business Analyst’s involvement becomes apparent over time.
When their attitude and their approach are constructive, everyone on the Scrum Team benefits from a better understanding of the domain and is clear on the value and definition of the work that needs to be done.
When they are destructive, the Product Owner and Business Analyst get drowned in analysis paralysis. The Developers on the team complete the existing work items faster than new work items can be defined, and a bottleneck appears.
In Conclusion
Not every Product Owner can wear the hat of a Business Analyst, and not every Business Analyst is ready to act as a Product Owner.
While the boundaries between these roles can sometimes be blurry, stakeholders, sponsors, and members of Scrum Teams should take the time to understand—and support—the need and value of having both.
