... your product has grown to multiple teams, and the teams are likely to develop along lines of specialization. The Product Owner wants to establish a new velocity for the Product Backlog.
✥ ✥ ✥
It is difficult and wasteful to get each and every member of a large development effort to estimate all of its PBIs. We want to recognize the ability of each individual to contribute from their perspective. In fact, key insights sometimes come from the most unlikely places. As human beings we all have insights into all human phenomenæ. However, that isn't reason enough to drag all of humanity into an estimation exercise. A good approximation is enough. It can be a waste of time for a hardware expert to give input on the layout of the GUI. Estimation is waste in the value stream and we should minimize its cost.
Teams naturally try to specialize over time, given the opportunity. There is no fundamental problem with specialized teams as long as the code base is open and teams estimate with the knowledge that they will freely work with each other during implementation.
The Aggregate Velocity approach does not depend on specialization and handles the fully general case, albeit at a cost of creating a large meeting. Individual voices tend to get lost in these large meetings, or the meetings bog down because of their size, or time boxing and other expediencies can cut off discussion prematurely. If there are more voices to be heard and if you believe there is value in hearing them, it will take more time to collect the key insights from a large group than from a small group. And though the time spent eliciting input goes up, the amount of unique insights goes at a disproportionately smaller rate.
Therefore, each specialized team estimates and develops items within its realm of specialization. These estimates are informed by input from other stakeholders in the PBI. You can elicit these stakeholders' input by first asking the team to make a first pass on estimation and by then refining the estimates whose domains extend outside the team's experience, inviting the external stakeholders as necessary.
✥ ✥ ✥
The team will feel committed to the estimates in the end.
Teams should not specialize along the lines of engineering technique; that is, there should be no testing team or coding team or architecture team. This pattern addresses specialization along the gradient of the value stream. See the patterns Market Team (which develops products for a given market), Localization Team (which adapts a product to an ethnic market segment), and Platform Team (which develops product increments targeted for a given platform).
Specialization creates stovepipes that could suffer from starvation in a given sprint. If team A specializes on domain DA and team B specializes on domain DB, and if the candidate Product Backlog for the current sprint doesn't contain enough items for team B, then either team A will end working on items outside its specialization or we will need to reduce the number of estimation points taken into the sprint. Solve this with Cross-Functional Teams, still focusing on specialization when possible but expanding each team's ability to do competent work in a broad number of areas.
This specialization was a contributor to the success of the oft-cited Borland QPW project, though it is important to note that QPW did not meet the team's anticipated schedule.
See also Team Per Task.