Scrum doesn't dictate that you have to be working on the one self-contained product. It simply states that there is a plethora of items that need to be attended to (the product backlog) and there is a certain amount of development time available in the next iteration (worked out from the project velocity). There are items selected by the client/business as having the highest priority from this pool of issues/tasks that will be done in the next iteration (the sprint backlog).
There is no reason that the product backlog and sprint backlog have to be from the one project - even in a single project there will be discrete units of work that are like separate projects: UI, Business layer, Database Schema, etc. Enterprise software development in particular is like this, where you have a number of code bases that all have to be progressing. The Scrum artifacts and process (meetings, questions, burndown chart etc) all work whether it is one project or multiple.
Having said that, in practice it is often good for each iteration to have a major theme - "do the reporting module" or "interface with XYZ system's API" - so that a lot of the issues come from one project/area and at the end of the iteration you can point to a large body of work and mark it as completed.