What in the heck do you measure on a project?

Alan has a great discussion on what to measure when running a project, Capacity vs. Velocity.  Questions around this have come up on all the projects I have worked on that wanted to track velocity, even before I was introduced to agile development. The answer seems to vary, depending on the project. This is a good read that provides good food for thought.

From experience and from talking with and coaching teams around Microsoft, management is always surprised with the level of overhead that they impose, once it is measured.  In one group, the overhead was over 60%.  In an average week, developers could only expect to spend two days actually coding.  The rest of their time was in meetings, reviews, triages, etc.  Folks were surprised at the amount of overtime required, until they measured the overhead.  Then, it became obvious why they always seemed behind the proverbial 8-ball.  Of course, this was the extreme.  Most groups I have seen and worked with (or in ) had much lower overhead.

On a past project, we measured the overhead, and our PM pushed very hard to minimize it as much as possible, to the point that we could code and test between 90-95% of the time.  It was great, and exhausting.  Try pairing for 8 hours in a day... it'll wear you out.  Of course, this is the other extreme.

How much overhead do you see in your job?  Is it closer to 100% than you want?  If so, can you fix it?

Comments (0)

Skip to main content