This blog is almost exactly the answer I made to a question from pent0x on pm.stackexchange.com (Best way to divide & assign development work on projects?)

Pent0x is a developer who is being assigned many tasks from various projects at the same time. He does not know how to complete his assigned work in time, particularly when he also has to deal with issues that arise in addition of his regular work. He really believe that there must be a better way to assign tasks than what he experiences – endures.

There is no Holy Grail answer to this question, but let me give you some food for thought:

Issues happen

This is not a real eye-opener, is it? Bugs, issues, defects or whatever you call them should not jeopardize the schedule, at least to a certain extend. Although rework is a loss of time, it happens in every (software) project and should be considered since the beginning. If every people – who are called “resources” in such a case – is stuffed with tasks at 100% capacity, any issue will make it 120%.

My advise here is to identify classes of service based on urgency and criticity, and allow some slack in the system so that the team can expedite important bugs when they happen without killing the schedule.

“[I]ssues […] you can’t always predict a time frame for”

So what? You cannot crystal-ball predict how long it will take to solve a particular issue : is this really going to change the fact that the issue must be solved? If so then maybe this issue was not that important after all, and some other tasks could have had higher priority.

When running too many projects at the same time, none of them will meet the schedule.

Running too many projects at the same time produces at least two effects:

• People have to switch between projects. Switching from one task to another is hard. Switching between projects is harder by an order of magnitude. When switching, people lose focus, experience difficulties reminding about the context and basically lose time.
• People have to deal with too many things at once. The human brain is not multitask. When someone has to work on several work items at the same time, the quality of his work will drop significantly. Not a surprise that making phone calls when driving (at least in France) or chatting with your neighbor in a classroom are forbidden.

My advise here is to limit the amount of work in progress at every level of granularity.

Pushing work

[…]and so most of my tasks that keep getting assigned to me start stacking on top of each other

Giving – pushing – work to someone is easy. When we tell someone to work on a specific task, we can then come back later and blame her for not having finished the assigned work, which is pretty comfortable, isn’t it? But by doing so we blind ourselves : we ignore systemic problems and transform them into personal problems. The PM won’t think “We have a problem with our process : we start too many things without finishing them…” but “This guy is really slow : look at how late he is“.

So my last advise will be : implement a pull system and visualize work. A pull system will make sure that the team “stops starting and starts finishing” (a Kanban adage, I can’t remember who said it first) while visualizing work might trigger some improvements in the way work is processed (“Don’t tell me that we currently have 26 work items at the same time for only 4 people?!”).