Business Analyst or Product Owner: Who Owns the Requirement

One requirement cut into lines, and who can change each. The product owner holds the order, the analyst the wording, the rule owners the numbers.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources - a published returns policy, help centre articles, ten public complaint threads I selected myself, consumer law and a walk through the published customer journey. No client, no interviews and no team. The case has a product owner only as a row in its stakeholder map, a role with a decision right and no name, and nobody in that role was asked anything. Every verdict in the tables below is mine [MINE], read from the case and from two public texts: the Scrum Guide and the IIBA's definition of business analysis.

Asking who owns a requirement usually gets one name back, and one name is the wrong shape of answer. A requirement is several lines, and each line has its own owner: the product owner holds when it ships and in what order, the analyst holds whether it is true, traced and testable, and the content of its numbers belongs to whoever owns the rule behind them, which is often neither of the two.

In short

• The Scrum Guide makes the product owner accountable for the backlog and its order. The IIBA defines business analysis as defining needs and recommending solutions. One text describes a decision, the other a recommendation, and the line between them runs through the middle of a single requirement.
• Cut REQ-014 into its ten lines and ask who could change each one. Four sit with the analyst, three with the product owner, two with rule owners who are neither, and one is split.
• The case breaks its own split twice: the analyst wrote the priority into a cell the product owner holds, and a question about release content went to someone who does not hold the release slot.
• A one-line answer to "who owns it" hides which of these three decisions you are actually waiting for.

What do the two source texts actually say?

The Scrum Guide is short and unusually blunt about this role. "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team." The accountability includes "Creating and clearly communicating Product Backlog items" and "Ordering Product Backlog items". Then two sentences that matter more than the list: "The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable." And on everyone else: "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner."

The IIBA's page on the BABOK Guide defines business analysis as "the practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders."

Side by side, the verbs do the work. The product owner orders and remains accountable. The analyst defines and recommends. Writing backlog items is work the Scrum Guide allows to be delegated, so an analyst who writes them does the creation while the accountability stays put. Neither text says who may change a threshold the finance team set, and the case shows why that gap matters.

Who can change each line of REQ-014?

REQ-014 is the refund-on-damaged-delivery requirement in section 4 of the case, cut here into its lines. Line 10 is the one exception: it sits only in the copy of REQ-014 on the requirements register template, and the case's own register has the other nine. The author wrote every line, because the case has nobody else. The last column is who could change it, read off the stakeholder map in section 2: row 1 is the Head of Customer Care, row 2 the Finance lead, row 5 the e-commerce product owner.

Count it. Lines 2, 3, 5 and 7 sit with the analyst: traceability, source, version, the clock anchor. Lines 4, 6 and 10 sit with the product owner: order, the form, where things go. Lines 8 and 9 sit with rule owners who are neither, the Head of Customer Care for the window and the Finance lead for the threshold. Line 1 is split, because the need and the promise inside it belong to different people.

Four, three, two and one. One person wrote all ten lines, and it would take four different people to change all of them.

What does the product owner hold that the analyst does not?

The order. Line 4 is the only line in REQ-014 that decides whether the work happens this release, and it is the line the case's author had the least right to write.

The case writes "Must have, release 1" against all five requirements, REQ-014 to REQ-018. Every one of those cells is the author's, and the stakeholder map gives the release slot and the shipping order to row 5. Section 4.1 then does the right thing in the wrong cell. It admits that "five must-haves in one release is a smell", names the one cut it would make (the scheduled deletion job in REQ-016 becomes a diarised manual deletion) and names the two it would refuse (REQ-017 and REQ-018, because "both are the safety rails on the change that moves money earlier").

That paragraph is recommending solutions in the IIBA's sense. Written into the priority column, the same view reads as a decision already taken. The fix is a relabelling: the column becomes "recommended priority", and the product owner's call goes next to it with a date. In Scrum Guide terms, section 4.1 is an attempt "to convince the Product Owner", which is exactly what it should be.

What can neither of them change?

Lines 8 and 9. The two numbers that most shape what the refund form actually does belong to people outside the pairing.

The 40 EUR threshold in criterion 3 is published policy. The product owner can drop partial refunds from release 1, which is what the fallback on OQ-05 does, but cannot ship criterion 3 at 35 EUR, and nor can the analyst. BR-11 gives the rule to "whoever signs off refund policy in Finance", and the open questions register adds that "nobody may change either threshold" until that slot is filled. Convincing the product owner changes the order of items. It does not reach a rule upstream of the backlog.

The 48 hours is the reverse case: the author's number, tagged [MINE]. Its change right still sits with row 1, because it is a decision window. The analyst may propose the number but not keep it against the rule owner, and the case expects this: "the design does not fall over if it becomes 72."

Where does the case route a question to the wrong owner?

OQ-05: "Do partial refunds ship in release 1?" The register gives it to the Head of Customer Care, due 30 April 2026.

Read against the map, the question has two halves with two owners. Whether partial refunds should exist in the new process at all is a policy matter, and it sits with whoever owns BR-11, which today is nobody the case can name. Whether they fit in release 1 is a release decision, and the release slot is row 5's. The Head of Customer Care holds neither half. The question is addressed to the one stakeholder who can approve the overall change, which is an understandable shortcut and still a misroute [MINE].

The one-page summary shows the same pattern. It is addressed to the Head of Customer Care and asks for four things by 30 April. The second of them, "Decide whether partial refunds are in release 1", is the release half of OQ-05, and it goes to row 1 rather than row 5. Option C on the same page costs "a delivery slot, not a configuration change", and the page names nobody who holds one. The decision summary asks the person who approves, and does not ask the person whose slot the work would spend. The build-start sheet in the discovery deliverables piece already lists the product owner under "who has to agree". The one-pager does not yet.

Both are the author doing the product owner's sorting by default, because no product owner was in the room.

The line-ownership sheet, filled in

One sheet per requirement, kept next to the register. Filled for REQ-014 from the case, with the mechanism note from the template copy.

The "kind" column is the one doing the work. Once a line is labelled as a fact, a recommendation, a constraint or a rule, the question of who changes it mostly answers itself.

The line-ownership sheet, blank

Where does this split stop working?

When one person holds both roles, the sheet still helps, because the kinds of line do not merge when the people do. A product owner who writes their own requirements still cannot move a threshold that Finance owns.

When there is no product owner, for example in a programme run through a change board, the priority and slot rows go to whoever holds the release order there. The analyst's rows and the rule owners' rows stay as they are.

Approval routing for the same register is worked through in requirements governance: who approves what, and when, the sign-off matrix in RACI for requirements sign-off, and what to do when every row says Must in MoSCoW or WSJF. The full case is at /case, the register as a template, the map with its decision rights as another template, and the tags are explained on the method page. Checks 01, 04, 05 and 14 of the scorecard are the ones a line-ownership sheet leans on.

All field notes · The portfolio guide · More in Requirements That Survive Review