Little’s Law, Multitasking and Getting Things Done

little’s law is the theorem of queuing created by john little , a (now retired) professor at massachusetts institute of technology.

little's law explained

algebraically, little's law is expressed as l = tw , where:

• l = the length of the queue.
• t = the rate at which items arrive or are removed from a steady state system (throughput).
• w = the wait in the queue.

therefore, if you want to work out the wait in the queue (i.e., how long before your job is looked at), you rearrange the theorem as w=l/t .

we see that the wait is proportional to the length of the queue and inversely proportional to the processing rate. this means that if your processing rate is slow, then the larger the queue is, the longer the wait before a new entry into the queue is processed. in other words, your ability to change — to be agile — reduces, whereas if your processing time is faster than your length in the queue, you will be processing items in the queue quickly. however, you run the risk of your system constantly starving for work.

example

imagine that you have a processing rate of one story every two days. this results in a rate of 0.5 stories per day.

if we have a queue size of 1, then w = 1/0.5 , or it will be two days that your story will wait in the queue before someone works on it.

now imagine that we push two stories into the queue: w = 2/0.5

for any additional stories entering the queue, it will take four days before they are looked at, thus slowing down our agility.

adding more resources (increasing throughput)

if i add more resources, i could process things more quickly. my throughput has increased, so things should improve.

suppose you now have two people, each capable of working on 0.5 stories per day. your processing speed has doubled to 1 story per day, as illustrated below. with a queue depth of 1, w = 1/1 .

the wait in the queue is now one day, therefore increasing our throughput.

let’s try to increase our queue depth to 2: w = 2/1

the wait is two days. our agility is degrading again. the more we assign to the queue, the longer it takes before the story is looked at. the problem here is that you cannot always add more people. people and resources cost money. so what else can we do?

reduce queue size

let’s try to reduce the queue size to zero. to keep things simple, we’ll go back to one person: w = 0/0.5

our wait time is now zero. we have complete agility — the ability to change stories until they are worked on. so how do we achieve zero queue size? well, we’re cheating a little. there is still a queue: the backlog. we are no longer assigning stories to people, so their personal "queues" (work in progress) have been reduced to zero. in other words, they are working on one story/task/item at a time and pulling new items from the backlog when they finish. this allows the changing of the backlog without affecting the work.

multitasking

one of the problems with assigning tasks to people is that folks have a tendency to multitask. another is the difference between what has been assigned to them and their thinking that they are making progress. this is actually not the case. let me explain.

say you have three tasks: a, b, and c. each task takes 10 days to complete. if we complete these tasks sequentially, it's going to take 10 days to complete each task.

now, if we do these tasks sequentially, it's going to take 10 days to complete each task.

but we are super people! we can multitask! get everything done quicker! is that the case? well, let's see. suppose we split the task so that we work five days on each task to get something done on all tasks.

we’re keeping it simple here.

so is it quicker to finish each task? umm, no. we have actually doubled the time it takes to complete each task.

this may not matter, as the overall time for all tasks is still 30 days. the same as if we did it sequentially. the problem is that switching tasks is not without cost. we have to dump our thought process on one task and reload everything for the next task. that takes time and energy, especially if the time between multitasking is hours or minutes and not days. second, if there is any delay in completing a "portion" of a task — for example, c took a little longer than first expected, and you spent six days instead of five — then you not only have delayed task c but also the completion of task a and b! and potentially the whole project. as a result, stakeholders of a and b escalate, because they need their projects done now, so you stop, rearrange, and the whole thing becomes a chaotic mess.

business as usual? for most people it is. so much so that for most it's a fact of life; so much so that when developers look at how long something will take to complete, they ignore elapsed time and focus on work time. but stakeholders focus on elapsed time, so as with any mismatch, tension rises.

conclusion

caveat: i should probably mention that these techniques are not going to shorten the delivery time for a set amount of work in a perfect system without losses, such as context switching or reorganizing, regardless of whether you have a queue size of zero or 50, or whether you switch tasks every few minutes. we are not doing any magic here. just like conserving energy, the amount of work being done overall in the system is maintained. we are rearranging things so that stuff gets done sooner, and if you prioritize your items to give the most value, you get more value sooner as well. we are also dealing with a system that has reached steady state. thus, there is a ramp-up time when the system is loaded and variances in the work from one item to the next are minimal — something that doesn't come naturally in any knowledge-based project.

i know my math is a little off; i probably could have explained it a lot better 20 years ago when i actually did math at university, but little’s law does represent a mathematical model of our ability to be agile. it shows that "pulling" increases your ability to respond to change as opposed to "assigning" work to someone. if you do assign, it shows that reducing the amount you load onto a person actually helps get things done sooner.

finally, if you do overload someone with tasks, because we are human we tend to change the way we work between those tasks, for whatever reason. what this means is that for any one particular task, it will actually take longer to complete it, due to the switch from another task. not only that, but a delay in one task could affect the delivery of other tasks that may be a higher priority.

so keep your work in progress small (preferably one thing at a time), try to keep the size of the work even and small in size to regulate the throughput to a steady state, and pull new work as required. you will get things done sooner, more smoothly, and we can hope that you may be one step closer to gaining control of the whole system. better yet, you are doing this all with no additional cost!