Product Owner vs business analyst: who does what

When an organisation adopts Scrum, the business analysts often ask the first awkward question: where do we sit? The Guide names three accountabilities and none of them is called analyst. That silence is not a verdict on the profession. It is a design choice, and understanding it removes most of the anxiety.

What each role is for

Business analysis, as it is commonly described, is about identifying business needs and determining solutions to business problems. The work includes investigating a situation, eliciting and documenting requirements, evaluating options and making sure a solution meets the need. It is a discipline that can be applied to software and to other change.

The Scrum Guide defines the Product Owner differently, as an accountability. The Product Owner is accountable for maximising the value of the product and for effective Product Backlog management, including developing and communicating the Product Goal, creating and communicating Product Backlog items, ordering them and keeping the backlog transparent. The Guide adds that the Product Owner may do this work or delegate it, and remains accountable either way.

So the first difference is one of accountability. A business analyst does analysis work for the benefit of a decision. A Product Owner makes the decision, in the form of the order and content of the backlog, and answers for it.

The overlap

In practice the activities overlap quite a lot. Both talk to users and stakeholders, both describe needs in words that Developers can build from, and both care about acceptance criteria. This is why the SBOK® Guide mentions analysts at several points: the Product Owner may draw on a group that includes business analysts, lead architects and senior developers when developing epics, and may bring a business analyst along to help the team understand a story during estimation.

The Guide's own phrase about delegation covers the rest. If the Product Owner delegates part of the backlog work, such as drafting items or documenting acceptance criteria, an analyst is a natural person to take it. The accountability stays with the Product Owner.

Three ways to place an analyst

As a Developer on the Scrum Team. The Guide uses the word Developers to include analysts, researchers and other specialists, who are the people committed to creating any aspect of a usable Increment each Sprint. An analyst on the team shares in the Sprint Backlog and the Definition of Done. This is a good fit when a lot of the Sprint's work is understanding and shaping the solution, for instance a data migration where the rules have to be discovered.

As support to the Product Owner. The analyst works closely with the Product Owner, often in refinement, preparing the next few Sprints' worth of items, and may or may not be formally part of the team. The Guide's Product Backlog refinement is the activity in which the Product Owner and the Developers add detail, order and size to items. An analyst who prepares well-formed items speeds this up. The risk is a hidden analysis phase that runs ahead of the Sprint and quietly recreates a handover.

As the Product Owner. In some organisations the analyst has the business knowledge and the authority, and takes the role. This works when they can order the backlog and speak for the stakeholders. It fails when the role carries the title and not the decision rights.

A worked example: the same story, three setups

This is an illustrative case. A bank needs a new rule about when a customer can reverse a payment. The Product Owner is a product lead with many calls on their time. A senior analyst has been supporting them for two years.

Under the first setup, the analyst is a Developer. In Sprint Planning they take tasks such as "document the reversal rules with compliance" and "write the examples that testers use". At the Sprint Review they explain what the rule means to the stakeholders who attend.

Under the second, the analyst prepares the backlog item for the following Sprint: interviews with compliance, drafts of acceptance criteria and a list of open questions. The Product Owner decides whether this item belongs above others and signs off the acceptance criteria. The Developers challenge the draft in refinement.

Under the third, the analyst is the Product Owner. They own the order of the backlog and must defend it to the bank's senior managers. They can no longer spend their days on the detail of each rule, and they need a Developer or a delegate for it.

The same skills are used each time. What changes is whose decision it is.

Skills that carry across

An analyst moving toward the Scrum model keeps most of their toolkit. Eliciting needs from stakeholders, modelling a process, writing precise acceptance criteria, spotting conflicting rules and asking the question nobody else asked are all as useful in a Sprint as in a specification phase. What changes is the timing and the size of the output. Instead of a complete document before building, the analyst produces just enough clarity for the next piece of work, then returns after the team has built it to see what was learned.

This is where the analyst's skill meets the idea of just-in-time refinement. A good analyst in a Scrum Team often becomes the person who asks "what is the smallest version of this that would teach us something", which is a high-value contribution and a different habit from completeness.

What goes wrong

• A separate requirements phase. If the analyst works a Sprint ahead and delivers a finished specification, the team is back in handovers. The Guide's cadence relies on items being refined to be done within one Sprint, not specified in full. See how much refinement is enough.
• Two owners. The analyst and the Product Owner each order the backlog. The Guide says the Product Owner is one person.
• The analyst becomes a translator. Developers stop talking to stakeholders and rely on the analyst's documents. Communication with users should remain direct wherever possible, which is also what the Agile Manifesto's principles say about business people and developers working together daily.
• Documentation as the product. The Increment is working product that meets the Definition of Done, not a set of documents about it.
• Identity loss. Analysts who feel they have no role leave or disengage. A clear agreement about what they decide and where they contribute helps.

How to practise it

If you are an analyst, write down which decisions you currently make that the Guide gives to the Product Owner, and which activities you do that serve them. If you are a Product Owner, list the work you could delegate. In the simulator the Product Owner role shows how much of the job is deciding, not documenting.