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.
3
-
1I'm not sure I understand your question. You do SCRUM. Why do you need resource planning. What is not working about your SCRUM approach?– nvoigtJan 28, 2016 at 22:19
-
1You are basing assumptions on the "100% utilization fallacy." You aren't doing Scrum, and it is unlikely to be agile. Consider a demand-based queuing system like Kanban instead.– Todd A. Jacobs ♦Jan 29, 2016 at 15:12
-
Well Kanban will not work with us because most of our work is contract base with a specific deadline– Amo A.Jan 29, 2016 at 20:08
Add a comment
|
3 Answers
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.
-
the key to choosing this answer is making the sprint shorter so that team works on a fewer projects at a time– Amo A.Jan 29, 2016 at 20:12
-
Welcome to PMSE, Roman. I made some minor edits to your grammar and syntax, but hopefully without changing the meaning of your accepted answer.– Todd A. Jacobs ♦Jan 29, 2016 at 22:26
-
Hi @CodeGnome, thanks for your edits. The answer looks much better now.– RomanFeb 3, 2016 at 16:27
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.
-
I will try to see the resource and capacity planning by focusing on the team as whole unit, yet model various types of “teams” in order to balance their use and best serve the business need.– Amo A.Jan 29, 2016 at 20:45
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.
-
Welcome to PMSE! I'm sorry to have to downvote this, but each Scrum team must work from a singular Product Backlog. While some people do this in the real world, it is rarely successful. This is a well-known Scrum anti-pattern.– Todd A. Jacobs ♦Jan 29, 2016 at 15:16
-
@CodeGnome cheers to your comment - I clarified that I don't see it as the best solution.– DIDoSJan 29, 2016 at 18:14