Scrum Teams work on one product at a time. The Product Backlog represents all of the work that needs to be done on that single product. The complete list of Product Backlog Items represents the goal of delivering all of the presently known features of a product. Multiple teams working on a single product, therefore, work from a single, shared Product Backlog. Working on Product Backlog Items from multiple Products causes the team to task switch into a different business domain and possibly into a different technical domain. Task switching creates wasted mental effort and therefore causes a team to be less effective than they could otherwise be. Having a single product to work on creates focus in both the business and technical domains.
The Product Backlog must be ordered so that the Product Backlog Items can be thought of as a sequence of valuable pieces of software to be built. There is always a first item (not two or three first items) then a next item, etc. until you get to the end of the list. The list is “ordered” so that there is a strict sequence with exactly one Product Backlog Item at each position in the list. The sequence is determined by the Product Owner and is used during Sprint Planning to determine what the team will do. This ordering helps to create a strong discipline around choosing what should be done next. It also encourages the Product Owner and the Scrum Team to think about how to break dependencies. If two or more Product Backlog Items have the same position in the Product Backlog, it means that the Product Owner has not prepared for the Sprint Planning meeting and the team may be less effective in that meeting. Having two or more Product Backlog Items in the same position in the Product Backlog is, in fact, a slippery slope that can lead to very poor prioritization, and even sub-optimal results from the team. Minor or occasional deviations from this rule will have a low impact, but categorizing Product Backlog Items into a small set of priority levels (e.g. MoSCoW prioritization – http://en.wikipedia.org/wiki/MoSCoW_Method) will reduce the effectiveness of the Sprint Planning Meeting dramatically.