How can an agile scrum team do multiple projects at the same time?

For an organization, it is common for developers of the same group to complete multiple projects. In this situation, how should we organize a team? How should they plan and allocate their work?

See http://www.21manager.com/html/2008/10-22/12562185.html for more information

　　
If many resources can be allocated (for example, six to ten developers can be assigned to each project), and the size and relative priority of these projects are known, generally, divide developers into two or more teams.
　　
Conversely, if each project can be assigned few people (each project can only have one to three developers), and the project size and relative priority are unclear or easy to change, it is difficult to divide teams in an effective way.
　　
Gilad Gruber is looking for the answer to how to build a project and team:
　　
I want to know what the best way is and how scrum handles this situation. I think the best way is that all teams share a product backlog (although this means that in a sprint, the team will deal with issues of different projects ). I think those who have a purely valid opinion will recommend splitting the team and building multiple backlogs.
　　
Wolfgang shulze zachau shared his experience:
　　
We only have one team and one product backlog that covers multiple projects, and there is only one product owner (PO ). After careful communication with the customer and other stakeholders, he has the final decision on priority. You only need to allow the Po to make their own decisions.
　　
"Of course, the premise is that you have a qualified Po," he said ."

　　
Xu Yi-Kaveri expressed different opinions:
　　
I am opposed to a total of product backlogs from multiple teams. Because Po is the person who decides the product backlog, and I think that basically the same person cannot be the Po of multiple projects at the same time.
　　
What he worries about is how to set priorities between projects, and this may affect the priority of generated features and the priority of projects. Therefore, he suggested:
　　
You should evaluate your team's ability to work, and discuss the differences in capabilities between multiple projects with the project manager. Next, select the product backlog entries for different projects based on the team's specific capabilities.
　　
Roy morien recommends that you choose between the two based on common sense:
　　
In any case, common sense must be recognized. If you can easily and efficiently split multiple teams, and each team has its own product backlog, you can do so. Each Pb can be assigned a separate priority. If multiple teams share the same backlog, this implies that multiple teams (each team has a proper number of 7 ~ 9 people) if the same Pb is shared, problems will occur when processing the priority of Pb, and "selecting entries and putting them into sprint backlog in a organized manner" will also become a headache.
　　
Finally, George dinwiddie showed up and (via the email list and blog) shared some of the problems he encountered when using multiple product backlogs:
　　
Estimation is estimation. Developers are likely to be in a situation where the workload quota is used up, either to continue developing an unfinished user story or to switch to another job. At this point, developers may be forced to work overtime, because the po may blame the developers for not finishing the task. In this situation, many things may happen, but almost nothing conforms to the agile principle.
　　
I told you, this is not fun at all, and it is not good for the business.