Ragrding regarding the product owner

Will he be from A or B?

Possibly, or even from a third company C. Product Ownership ought to be seen as a profession in its own right, and it has its own skill-set independent of whatever product is being developed.

If from A: how can he recognize the details of the requirements of another company?

He may not need to recognize the details at all. Instead, those aware of the details may need to recognize him as having authority over how product value is best maximized, and collaborate with him accordingly.

If from B: should he be a system analyst to make use cases?

He should be the person whom all stakeholders accept as holding authority on all matters of product value. It is possible that this person might be a system analyst, and that he or she might decide use cases are the best way to construct the Product Backlog.

Ian Mitchell

Many thanks for your reply

You said:

He may not need to recognize the details at all. Instead, those aware of the details may need to recognize him as having authority over how product value is best maximized, and collaborate with him accordingly.

Ok. what I understood from your answer is that the product owner will set with (those aware of the details) or let we say the customer, then the product owner will gather the requirements from them…is it right?

If yes, I think we don’t need a system analyst in the scrum development team, do you agree with me?

It could be from A or B and should not be a Proxy Owner. There should be no only handoffs from domain expert from company B to a person in company A and then to the delivery team.

If person with domain knowledge does not exist within company A then person from company B with domain knowledge should be the PO and a person from company A can shadow and upgrade the knowledge to takeover.

Hi,

To illustrate Ian's answer, this is an example I lived.

It's a bit different than your company A and company B as it happened within one company, but between different services.

I was scrum master in the IT department and we worked in a company that generates payrolls.

As we, developers, didn't know anything at payroll legislation, we needed a Product Owner who could lead us in terms of functionalities and product vision.

It was decided this PO would not be from our service. She was a prior payroll accountant manager with a global knowledge of payroll legislation, from the production service. (you can think of it as company A/company B)

But, as in France the legislation is extremly complex, there was no way she could know everything. So she relied on an accountants team, experts in several fields of payroll legislation.

I guess what I'm trying to say is, you don't need your team to have a expert or an analyst, what it needs is someone (the PO) who has a global vision of the product, and knows who he/she can rely on to gather information.

This person doesn't need to be on your team or company, he/she can be on client side or whatever.

What is most important is that he/she dedicates the time and energy needed by the DevTeam to understand the functionnalities to develop. And he/she gather the information and redistribute it to the DevTeam as her one and only source of information.

And if you choose to keep the PO in client side, try to physically see him/her regularly (Sprint Plannings, retrospectives). Try to avoid the proxy PO thing, as it leads to confusion on who is really responsible of the Product, and on their prerogatives. If you team is distributed, there are several tools to works virtually, like RealTimeBoard for instance.

many thanks for all of you