I second the Gantt chart approach. The way I modelled is in a spreadsheet, 1 cell = one week. Then on a top row write the number of engineers available. Discount 10%-20% for PTO (there's always someone in PTO).
In the 1st column write the projects and next a column with your estimates of man-weeks required. Here is where you should modulate the estimate depending on how business looks at these things: Do they know it's an estimate planning tool? Add the 30% overhead of your estimate: Shit always happens. Does business take your estimates as law? Add 50% padding.
Once you have that framework, get the milestones/end dates from business. These usually come as "having X feature in Q1", Y feature in Q3. So you have some leeway.
Start mapping how many engineer weeks would you need for each task for each week to finish in the milestone, ensuring you dont get to negative in the top (total engineers) row.
You also should consider the mythical man month: putting 10 engineers in a feature will most likely make it fail, not go super fast. Usually you want 3 or at most 4 ppl per project. This also depends on the size of the project.
With this data, you'll be able to show business that additional prioritizing needs to be done. On the flipside, they will question you your time estimates. You can use that to push to sit down and clarify/detail the project, maybe even split it in stages: the Gantt will allow you to model feature releases of a large project.
I used this framework successfully, and it served as a great communication tool between the CEO and myself (as head of Engineering).