How to divide product development of a product between scrum teams?
I am struggling with the concept of scaling as the workload increases on a product.
Should the various teams could all draw different of work from the backlog by taking responsible for a set of components?
Or would a split in features make more sense?
Or is a split in technical layers recommended in this case (despite affecting the autonomy of the team)?
Why do you believe the teams need to be split by technical layer specialization, or component/feature specialization? Read up on scaling strategies like SAFe or LeSS to learn how multiple teams can work on one product.
Should the various teams could all draw different of work from the backlog by taking responsible for a set of components?
Or would a split in features make more sense?
Or is a split in technical layers recommended in this case (despite affecting the autonomy of the team)?
Where is the business value found? In having feature complete increments available, or in providing components or layers?
Wherever it is, each team should be able to provide value in those terms. They should also seek to minimize the dependencies between them, so each team can proceed without impediment and meet its goals.
The more features have dependencies, the more this will show up in the Nexus Daily Scrum. At least that is my experience. I wouldn't be afraid to break up feature sets if you can't find the dependencies at the beginning. It all comes out in the wash, so to speak. Don't be afraid to use the Nexus to figure it out.
My questions was actually in context of the PSPO1 examination that I am preparing for. So far I have found the following frameworks for scaling: Less, SAFe and Nexus. Then I read this article https://www.scrum.org/forum/scrum-forum/5533/method-wars-scrum-vs-safe… scaling framework is applicable for Scrum.org PSPO1 exam? Or should I understand and memorise all three?