Scrum really doesn’t dictate that you have to be working on the one self-contained product. It simply states that there is a bunch of stuff that needs to be done (the product backlog), there is a certain amount of development time available in the next iteration (worked out from the project velocity) and there are items selected by the client/business as having most 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 – the UI, the business layer, the 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 process – meetings, questions, burn down 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 or area and at the end of the iteration you can point to a large body of work and place a tick against it.