Scaled product with multi Scrum Team.

You seem to be saying that you are the PO for the "core component" and that other "modules" (trading, maintenance, deposit) have separate ownership.

Are these in fact separate products? Can feature-complete increments be delivered for each of these discrete elements?

Hi,

Agree with Ian that there is a dependency on whether you are PO of the whole product or the core component only.

The only other thing I'd add is that I would not recommend changing sprint lengths unless there are really exceptional reasons. Makes all sorts of things harder to manage including velocity calculations.

Andrew

Hi Ian, thanks for your reply.

Actually, they are not separate products. All of them are part of the same product & have to be delivered at one, together.

Thank Andrew Lishomwa for your suggestion.

Do you mean i should work with others PO to redefine the expected date, then try to commit with it ?

> All of them are part of the same product &
> have to be delivered at one, together. 

Who then is the PO for that product? Is it you? You say that "your" team is only responsible for the "core component".

Let me explain more detail:

These parts (core, trading, maintenance, deposit) are belong to 4 separate projects, in charged by 4 separate teams.

They are relative independence. But one of them can't be released standalone.

Mean, each of them is a sub-product which is defined clearly its input, output so we can develop one of them independent.

Only relation between them is that: They have to go live together (During development, they are independent with each others)


Other sub-product's NOT used Agile/Scrum (We dont need to care their methodologies). Just my sub-project (core app) is used Scrum.

Whole these sub-projects are managed by one person (Program Manager).

It seems that you have projects and not products, and project managers rather than product owners. Moreover, the product you actually do have does not appear to have a product owner at all. Instead there is a Program Manager.

I don't see any evidence that Scrum is being understood and applied in this situation. The basics aren't there. Certain things have been renamed by misapplying Scrum terms to non-Scrum practices. This will only serve to cloud understanding of the deep changes that are needed. Before going any further, I recommend that you study the Scrum Guide and critically re-appraise your current way of working.

Agree with Ian.

The work has been split inefficiently (by technical/system silo), which creates a significant integration effort to even understand whether the separate pieces can function well together.

For Scrum to work, each of your sprints needs to provide something valuable and tangible to the business. It doesn't seem like that is the case.

From a PO standpoint, you should always be analyzing and prioritizing your backlog. If they are proposing a completion date, you should have some idea what can be completed within your backlog by that date.

You also need to understand what "done" means to these other traditional teams. While Scrum teams can work with other non-scrum efforts (ex: outsourced vendors), there should be some common idea of what is needed for release.

But as others have already pointed out, the separate projects are still being managed in a traditional, non-Scrum fashion.

Thank you all for your suggestion. I get much more clear now.