Capacity and Over-Committing Your Resources!

You have a development team. Your stakeholders and project sponsors want to make the most out of your team. They’d like to see your current capacity and squeeze out as much as they can out of every resource you’ve got.

Do they have free time? Put them on another project.

Can they help out here? Put them on that project.

Ugh. Kill me. There has got to be a better way. Capacity is an interesting metric to measure. Some people simply do an equation like so:

Working Hours Available per Day (WH) ((x)times) Days Available This Iteration (DA) ((=) equals) Capacity


WH x DA = Capacity

But this seems way too over simplistic! I mean, are our developers really working 8 hours a day on code? What every happend to “ideal man day?” In teams I’ve worked with, an ideal man day is 5-6 hours in length. In many cases, 5 hours a day seems more reasonable. We have to account for interruptions (hopefully not many), meetings, and other things that come up in the day. A good general rule is that we shouldn’t try to exceed 70% of an individuals capacity. In reality it’s closer to 50%.

The problem with the 100% utilization mindset is that we have assumed that our outcomes of an iteration are fully deterministic… but we all know pragmatically that this isn’t true. Software development is unpredictable at times!

A couple of steps to help us look at capacity when it comes to our projects:

  1. Individuals calculate realistic capacity
  2. Applied honest estimates to their tasks
  3. Targeted a maximum capacity of 50%-70%
  4. Understand capacity over the long haul with velocity and story points – What is the average story point completion by team/individual?

When capacity planning is done well we can feel good that we all have done our best to provide a realistic commitment to achieving the completion of all stories for the iteration.

[Image Source:]

10 Replies to “Capacity and Over-Committing Your Resources!”

  1. This is the exact problem. Most PO’s and/or directors see capacity exactly as you have expressed it in your formulas. This is a completely farcical calculation of capacity when it comes to agile teams, especially when talking about allocation in development projects.

    Capacity should be calculated in Effort or Story points, never in hours. There are days where I code for 10 hours straight, however they are very rare. There are other days where I may legitimately code for 2 hours. When you have cross-functional, cooperative teams, time is burned doing other tasks, mentoring other individuals, etc.

    This is why many agile projects fail, in my opinion. If the client or product owner doesn’t buy-in to agile principles and the idea of capacity calculated by effort points, you’re going to experience team burn-out at the very least, if not outright project failure.

    1. Completely agree with you here. As a developer myself that was always my biggest gripe!

      Full development is so much more than just sitting and coding. It’s:

      Working with coworker
      Test scripts
      Other tasks

      While this isn’t always perfect, in my experience I’ve found that week to week, hours are OK, but in the long run, points make more sense (for planning). Depends on the situation though. Regardless, the whole idea of developer capacity is a term we need to get rid of.

  2. Great post. From conversations I’ve had 70% seems to be the magic number at which to set capacity. But orgs continue to over-allocate to 100% anyway, and wonder why their projects run over…

    1. Exactly. Developers need to give feedback and pushback to management and let them know that they don’t CODE 8 hours a day. Thanks for reading and sharing!

  3. How I wish people were not referred to as resources – is it possible to use team mmebers or people? How I wish project managers didn’t assume resources belong to them. It is one of the things I like about Agile where we are implementing it – the concept of whole team – no hierarchy. In relation to over commitment – I have found all roles poor at estimating hours in both waterfall and Agile. However when the team remains consistent, after a few weeks, using story points, does seem to allow reasonable estimating.

    1. Totally agree! People are people, not like gold or a rock… a resource. Ha~~! The exact point is learning what your team can and cannot do over a time period. That will help the team understand it’s capabilities! Right on!

  4. I am OK with the 70% rule on allocating time towards a team member (notice I didn’t say resource — thanks Mary!) but let’s not ignore the 800 pound gorilla in the room. Developers aren’t always the best estimators (I can say that because I’ve done development for years). So no matter what measuring stick you use for estimates (story points, person hours, or drawing tally lines on your cave wall), if the team member under or over estimates the work, it wreaks havoc on the 70% rule.

    Luckily, this is easy to solve. Have each team member estimate their tasks and track their time towards it. Then after the sprint ends, do a variance report (estimate minus actual). You will find that on the first go-around most of us will underestimate the tasks.

    Then on your next sprint, collect estimates from each team member, but buffer them by the variance (based on the individual team member) from the last sprint. So if John was 25% over variance on his aggregated tasks last sprint and he estimates 100 hours for his tasks in the upcoming sprint, make his estimates 125 hours (works OK for story points too).

    Then in your retrospective, take the same approach (look at the variances in the new sprint and make buffer adjustments accordingly). Over time, you build a much better estimator and more reliable estimates.

    If the team member does not improve over time, beat them with their measuring stick. Now I will get back to drawing tally lines on my cave wall…

Leave a Reply