I have to disagree. I think it is key to the process to have a team focused on a single project during a sprint. If you have some specialists that can't contribute to the entire development process (content authors, graphics people, business process analysts, etc.) I would shuffle them off the team when they can no longer contribute. Or better yet, get them trained up on some different tasks so they can contribute to things like testing.
Another thing to keep in mind is that running projects in parallel kills your schedule. Consider this: for simplicities sake, lets say we have 5 projects using the same team and starting on the same date. Each project needs 3 one months of effort, In the best case scenario running parallel, you will finish them all at once and it will take 15 months. Your velocity will get creamed because you can only fit 1/5 of a month of effort in a single sprint. You'll also be doing 5 demo meetings all at the same time. So best case scenario, you deliver your 5 projects in 15 months and your competition will be claiming they could do the same work in 3. Your teams estimating maturity will suffer because they will only be able to consider 20% of their available labor. You may find that you actually are unable to perform some tasks in a single sprint. If you have to change the number of projects being worked from 5, your team will have to adjust their estimating habits which will damage the teams efficiency. Additionally, your team will find it difficult to self-organize when a simple task reassignment may require spinning up a new dev environment before work can begin.
If you were to run the same 5 projects serially, you'd deliver the 5th project in the same 15 months, but you would have educated your client that your team is in such demand that you have a 12 month backlog and that you can use that time to refine your project goals. Or if you have a constant backlog, you know it's time to start hiring another team. Your best project, however, is finished in 3 months with a client that has seen rapid improvements during the active period. You're able to finish that project a year earlier and can put it on your resume. Your sprint velocity will stabilize over that period of time and you may find that hits its stride after a project or two and are able to accomplish more in a given sprint.
I think running projects serially is one of the biggest hurdles an organization attempting to adopt scrum faces. It's a major cultural change associated with deconstructing the project manager role, but the benefits to the scrum process are huge.
Keep in mind that EVERYBODY does not need to be a full team member. They can be engaging your client in the waiting room, preparing for the development process. I keep my business analysts, network architects and graphics design people as domain experts and only attach them to a team as needed. Let them run with sprint 0. You'd be surprised how engaging working on look-and-feel and workflow is. It's also good to prepare your client with the understanding that when development begins in earnest, their level of participation may actually go up and that it is important for them to be available. Let them know the schedule so they have plenty of time to deal with things like vacations and holidays well in advance.