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

Or

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: technet.microsoft.com]

FacebookTwitterLinkedInShare

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

  1. Michael Gerety
    January 4, 2011 at 8:23 am #

    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.

    • peter
      January 4, 2011 at 9:07 am #

      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:

      Coding
      Compiling
      Checking
      Working with coworker
      Test scripts
      Regressions
      Coding
      Other tasks
      Etc.

      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. Cheryl Harrison
    January 4, 2011 at 10:12 am #

    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…

    • peter
      January 4, 2011 at 10:58 am #

      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. Mary
    January 5, 2011 at 4:46 am #

    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.

    • peter
      January 5, 2011 at 8:17 am #

      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. Steve Miller
    January 5, 2011 at 4:20 pm #

    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…

    • peter
      January 5, 2011 at 5:56 pm #

      Interesting thoughts here! Thanks for the comments! I know of exactly a client that can use this. Thanks for the tips!

Trackbacks/Pingbacks

  1. Tweets that mention Capacity and Over-Committing Your Resources! | Agile Scout -- Topsy.com - January 4, 2011

    […] This post was mentioned on Twitter by Tony Askew. Tony Askew said: RT @agilescout: Capacity and Over-Committing Your Resources! http://goo.gl/fb/hntuj #agile #pmot […]

  2. Working on Multiple Agile Teams | TechWhirl - April 8, 2014

    […] A simple definition of capacity planning from Wikipedia states that it is “process of determining the production capacity needed by an organization to meet changing demands for its products.” From the agile perspective, capacity planning involves determining the length of the sprint and your workload capacity for that sprint for that project. It’s especially critical when your team members work on multiple teams. Without capacity planning, your team members can easily lose track of what time is committed to each team. And, you run the risk of also over-promising to one team or the other if you don’t do a thorough plan with actual numbers. For an easy primer on capacity planning, see Capacity and Over-Committing Your Resources. […]

Leave a Reply