Measure Throughput, Not Utilization

Keeping your team busy with work all of the time may seem good for productivity and a good use of your work force. But it comes with serious backlash in the form of delayed work, incomplete iterations, technical debt, and the negative consequences of multitask context switching. In this column, Johanna Rothman explains how teams should focus on throughput and not the conceived benefit of 100 percent utilization.

Many managers think that 100 percent utilization of people is a desirable state. "If we keep people busy, we'll get more work out." One hundred percent utilization might work for piece work or time-based work, but in knowledge work, utilization doesn't work that way. Once you get past about 80 percent utilization, you get less done, because there is no slack for people to take up the work that arises or to think about how to do their work better. You also incur technical debt and the costs of multitask context switching. That's because project work is just one of the kinds of work we do.

Work Is More Than Project Work
In addition to project work, we also have: time-based work, such as periodic work-those monthly reports or yearly budgets or training or vacation; ongoing work, such as support for the operation of an organization or department; and in-process, ad hoc work—those emergency projects, work you are doing as the result of crises or other surprises. And, let's not forget our management work.

If you ask people to work 100 percent on project work, they cannot help but neglect the time-based work, especially the ongoing or ad hoc work. But, people have consciences, so they postpone project work to take care of emergencies. They will ignore any management or strategic work because the urgent work takes precedence over important work.

The problem is that the ongoing or ad hoc work is urgent and keeps the organization going. For example, fixing customer-discovered defects keeps the customers happy and keeps senior management happy because they are not hearing about problems. But, the important work, such as discovering how the defects arose or how to automatically find them, allows the organization to change how people work or what people do, in order to increase everyone's capacity.

You certainly want to achieve zero ad hoc work in an organization where projects provide the means to continue the organization's work, and I don't know a single organization that has accomplished that goal. You somehow have to finish enough of the urgent work so you can achieve the important work. If everyone is 100 percent allocated to projects, they cannot think about anything else.

Slack Enables Throughput
Even if you have no ad hoc or ongoing work, keeping people 100 percent busy guarantees their throughput will decrease.

Here's an example: An organization new to agile has four product owners and two project teams. Each product owner is pushing his work on each team. That means each team is contending with two product owners and their backlogs. Each product owner wants his work complete in any given iteration. Because of the pressure, developers start signing up independently for stories, not planning and estimating an iteration as a team. As one product owner said, "I can make sure my developers are busy every minute of every day."

The developers attempt to "finish" their development work in the two-week iterations. After the first iteration, the testers realize they cannot complete their testing inside the two-week iteration, so the product owners demand the testers test in the following iteration. The developers think this is OK, and the testers reluctantly agree.

After the second two-week iteration, the developers mark their stories as complete. But, because the testers have not yet finished testing the work from the first iteration, nothing is actually marked as done. And, the testers have interrupted the developers with questions.

After the third iteration, still nothing is marked done. The developers are not helping with hooks into the code for tests, because they are "too busy" trying to finish all the development.

The people on the teams are now siloed instead of working as cross-functional teams, they do not have a common definition of done, they have tons of work in process, and the developers are concerned their open defect count is growing because they are not receiving any tester feedback. The teams' velocities have decreased.

At the next retrospective, one of the developers explains the problem and that it's only getting worse. The team generates a cumulative flow diagram, as in figure 1. The technical staff and the product owners all agree: They must do something different.

Figure 1: Initial three iterations on a project with no slack

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for and projectmanagementcom and blogs on her website,, as well on

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!