Queuing Theory and Agile Backlogs

Queueing theory (1, 2, 3) and Lean pull-based queue systems provide some insights into why agile backlogs such as the product backlog found in Scrum are done they way they are.

Updated! (originally published April 6, 2005)


Typically, an agile team works by taking iteration-sized chunks of work off of the project backlog. Even though items on the backlog do not need to be the same size, by taking several off the backlog at a time, the total package of work for the iteration can be made a consistent size. The backlog is prioritized so the agile team is always working on the highest-priority stuff. So far, this is great: the work packages are consistently sized (iterations are always the same duration and with the same team), and generally small so the team is working at high utilization. However, individuals in the team may not be at a high level of utilization.

Utilization Graph.gif

A basic lean pull-based system operates so that as a “server” (i.e. the project team) completes a piece of work, it pulls another piece off of a queue of work items and begins processing that item. However, agile methods say nothing about how long work is waiting in the queue. The work in this queue is in progress as far as the customer/client is concerned. Therefore, from the customers perspective, the time-to-delivery of an agile team is not managed because the size of the queue of work is not being managed. In most agile methods, including Scrum, there is no “gating function” that determines what work can be added to the backlog and when to add it. The Product Owner controls the backlog priority and maintains it. However the backlog

represents everything that anyone interested in the product or process has thought is needed or would be a good idea in the product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases. (Agile Software Development with Scrum, p33.)

So what is happening? There is an implicit gating function occuring that releases work into the team’s iteration. That gating function is based on the Product Owner prioritizing the backlog and refining the items so that they are small enough for a single iteration, and the team estimating the high-priority backlog items so that only enough for one iteration is released.

In terms of Little’s Law, the team has deliberately pre-determined the average time a work item spends “in the system” (iteration). Therefore, the number of items taken from the backlog varies per iteration.

Is there another way to do this? What if the team, instead of being considered a single server, was examined from the perspective of the individual people doing the work?

In this case, the backlog would have to be managed differently in order for the system to work efficiently. First of all, the size of the backlog would need to be fixed. Then, items put on the backlog would all need to be of the same size in terms of man-hours. Instead of having iterations, the people on the team could each take items off the backlog independently. Finally, everyone on the team would have to be fully capable of doing any item on the backlog from start to finish. The Product Owner would then be responsible for replenishing the backlog.

Uniform Backlog.gif

In this scenario, iterations do not really make sense. However, this way of managing the backlog is only possible under the following conditions:

1. Work can be normalized into independent equal-sized packages.
2. Individuals work at roughly the same rate.
3. A single person is able to take full responsibility for a single work package.

We can see from this list of conditions, that for most creative endeavors, this is not realistic. This in turn points us back to the way that Scrum and other agile methods are designed. A team’s velocity (rate of work completion) can be determined after a few iterations because work packages are broken into iteration sized chunks and because the team represents a single server in the queueing system. This in turn leads to much more flexibility in both the type of work packages that can be handled and the level of skill and specialization that the people constituting the team can have.


Check out the short whitepaper I’ve written about the relationship between lean and agile.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.