Estimating for the bottleneck

Your Agile team may employ an estimation technique that requires the participation of all team members. But this kind of all-hands involvement is completely unnecessary if you know where your bottleneck is.

Finding the bottleneck

If you can picture your development process as a chain of dependent operations that are performed in sequence (e.g. development, testing, deployment), then one of those operations will be your bottleneck. And just so we’re clear about what is meant by “bottleneck”, here’s a working definition:

A bottleneck is any resource with no spare capacity.

In other words, one of the operations in your development chain is going to set the pace—to determine the rate at which work items are completed. Find the operation whose throughput matches the throughput of the entire chain, and you’ve pegged your bottleneck.

All-hands estimation is unnecessary

Conventional estimation sessions, even within the Agile community, include input from all team members. It’s common to see teams arriving at an estimate for a given unit of work (e.g. user story, backlog item) by summing the anticipated efforts of each operation. (Development will take 3 days and testing will take 2 days, therefore the final estimate is 5 days.)

The problem with the above scenario is that it assumes that no work is done in parallel, which is rarely the case. In reality, development and testing will be occurring simultaneously most of the time, and the production rate of the bottleneck operation will determine the production rate of the entire chain.

When all operations in the chain are working in parallel, and assuming that there are many units of work to be done, then the time to complete a given unit of work is determined solely by the time it spends at the bottleneck operation. Therefore, in the above scenario, the time to complete the unit of work will be closer to 3 days than to 5.

This means that there’s really no need to involve the entire team to arrive at estimates. Getting estimates from team members involved in the bottleneck operation only will yield appropriate results.

What if we can’t find our bottleneck?

I often hear teams reporting that they have multiple bottlenecks, or that the bottleneck jumps from operation to operation, making it difficult to “estimate for the bottleneck.” If this appears to be the case in your development chain, then you’re most likely observing BINOs (Bottlenecks In Name Only). In any give chain of dependent operations, there will be one true bottleneck. There are several techniques for revealing where it is:

  • Observing Inventory Buildup – Find the operation that has the largest growing volume of work to be done.
  • Matching Cycle Times – Find the operation whose cycle time matches the cycle time of the entire chain.
  • Assignment – Where two or more operations have similar production rates, choose the one you wish to set the pace for the entire chain.


Although the example above talks about estimating in absolute time (days), I highly recommend estimating in relative time (points). We’re generally not very good at estimating in absolute terms, but can be quite adept at relative estimation (e.g. unit of work A will take about twice the time as unit of work B).

See my previous article, What are we estimating, anyway?

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

That bottleneck may be right where you want it

Mere mention of the word “bottleneck” is often enough to generate a flurry of proposals on ways to eliminate it. But every system has a bottleneck, and yours may be right where you want it.

A useful definition

Examples of bottlenecks, both at work and out in the world, abound. Work piles up on the desk of a co-worker who is out sick. Traffic comes to a standstill on the freeway while driving to and from work. (The most common one in my commute is a particular spot on Highway 101 north of Novato where three lanes turn into two.)

But some things that we think of as bottlenecks, aren’t. In a work environment, it’s common for people to label anyone or anything that is preventing them from starting their own next work task as a bottleneck.

A more useful definition of bottleneck comes from The Goal by Eliyahu M. Goldratt:

“A bottleneck is any resource whose capacity is equal to or less than the demand placed on it.”

That’s a powerful statement. And it’s the “equal to” part that I find the most interesting. If you turn the definition on its head, you can express it as:

A bottleneck is any resource with no spare capacity.

The bottleneck is a pacesetter

It’s convenient to think of a software development environment as a chain of dependent operations (e.g. requirements gathering, design, development, testing, deployment).

The bottleneck in your software development environment is the operation with no spare capacity with respect to the demand on your chain of development operations as a whole. If you measure the rate at which finished product is leaving the end of the chain, you can identify the bottleneck by finding the operation whose production rate matches the system’s rate.

In other words, the bottleneck operation sets the pace of production for the entire system. And that’s why I find it useful to refer to a true bottleneck as a pacesetter.

Deciding whether or not to eliminate a bottleneck

Your system is going to have a bottleneck somewhere, and fixing a bottleneck at one operation will have the effect of moving it to some other operation. You only want to move a bottleneck if you don’t like it where it is.

So how do you know if your bottleneck is in the right place? Just take a look at the rate of production of your development environment as a whole. If delivery of finished product (e.g. features, user stories, or whatever units of work you use) is keeping up with demand, you’ll likely want to leave the bottleneck where it is.

And how do you assess demand? In a software development environment, demand might be determined by your marketing organization (i.e. “We need to have features A, B and C delivered by the end of March”).

A bottleneck side-effect

A development environment that is keeping up with demand, and that has a well-managed bottleneck, will also exhibit what is often perceived as an undesirable trait: Not every operation in the development chain will be occupied 100% of the time. In other words, some people are going to appear as if they’re not working at least part of the time.

But this is intentional. If the bottleneck is the pacesetter for the entire system, then all of the non-bottlenecks will, by definition, have spare capacity which can be used, when appropriate, to make sure that the pacesetter operation is never starved for work.