Thursday, November 6, 2014

Velocity vs Capacity

Interesting to watch teams as they plan for a release and attempt to keep their 'velocity' constant as they move from release to release.

In my mind, teams need to strive to increase velocity.  This doesn't mean that I don't think they are working hard enough or that I think that people need to work longer hours.  In fact, I'm sure we have all heard the phrase "work smarter, not harder" as we've progressed through our careers.

I watched a bunch of people present a release plan this week and I saw something interesting.  Teams explained how the plan that they were presenting was right because the velocity was either the same as last release, or explainable as to how it was different.  This highlighted for me that there was a fundamental disconnect between a teams velocity and their capacity.

As a startup company, velocity and capacity are often the same since teams don't tend to have distractions other than getting V1 out the door.  After V1, teams are often distracted by customer issues, internal meetings, audits, reviews, you name it.

Capacity is how much work a team can get done.  It's an input.  Assuming I have the same number of people and the same amount of interruption, I should have a constant capacity.  My Velocity however is the portion of that time that I am actually executing against the backlog of stuff that actually holds value to my customer.  It is what I output.

If we are actually doing our jobs, we are reducing distraction and increasing our velocity from sprint to sprint and increasing the rate in which I provide value to my customer.