I lead a team that currently has 9, soon to be 10 people (if you include designers) with about 15 projects at various stages of progress at the moment.
I'm peripherally involved in all of them (in a project and product management capacity and for code review), but work directly on programming, architecture, and design for 3-4. I only contribute code on one or two at any given time.
Most of our individual contributors are generally only working directly on one significant project at once, two tops if one is in acceptance testing, and maybe planning for a third; plus maintenance as it comes up.
If they have more than that, there's a clear order of priorities such that we expect them to finish one thing before turning their attention to the next.
But the "plus maintenance as it comes up" part can mean someone can have easily two dozen open tickets assigned to them. Again, we have prioritization rules of thumb. We expect one ticket to be at least deployed to an acceptance testing environment before picking up the next - unless we get something else that comes in as higher priority. Fixing a ticket rejected from acceptance testing takes higher priority than starting on a new one with the same nominal priority in our issue tracker.
If you're working on a larger project, you're only supposed to interrupt it for tickets above a certain priority or to fix acceptance testing bug reports on your last project. Then each engineer takes a 1-2 week break between projects to clear the project board a bit.
The result is that an engineer can easily end up working on a dozen different maintenance tickets in the space of a particularly bad week (we have a legacy codebase with little automated test coverage, and certain deploys result in awful cascades of bug reports). And one can easily have a very full backlog of assigned tickets. But no one has more than one active, one in-testing, and one in-planning project large enough to really consider a project.