We are a software development agency, We have a small team of 6 developers using Scrum software development framework, handling small projects around 2 weeks more or less, in a single sprint (2 weeks) we usually handle 3 to 4 projects. How do you approach developers planning (Resource planning)putting in mind trying to optimize developers utilization to the maximum and minimizing waste.
There are couple of things you can do here. I'm not completely sure that resource planning is something you need to solve. It would be better to adapt your process by making sprints shorter so that team works on single project at a time.
Another idea would be to split the team to make sure that they work on a single project at a time. Scrum by itself is designed to handle development of a single product.
First, pleeease stop saying resources. It sounds like you're scheduling oil to be transported along a pipeline.
If you are using the Scrum framework, then the answer is:
Development Teams are structured and empowered by the organization to organize and manage their own work.
Optimizing utilization is will push you to silo developer activites, queued development workflow and very non-agile, non-lean development practices. Now that you've created those problems by optimized utilization, you'll need to manage through command and control. These are all really bad things and will directly result from try to optimize developer time rather than letting them organize themselves.
Resist the urge to micro-manage the team. Make sure they are cross-functional and let them go. They'll succeed and fail. They'll retrospect and improve. This is the spirit of development that Scrum supports and encourages.
The cleanest way would be to have multiple product backlogs and to assign one team to one backlog. It is also possible (but not suggested) to have a team work on multiple product backlogs. If you really need to, you can merge the backlogs to one backlog to prioratize the stories between each other. If the projects are very small (as you said), then you might just merge them in sprint planning.
As @CodeGnome commented: It should not be the aim - but works for us in real-life.