The Regenerate Web

Johanna Rothman has been blogging about Estimating Tasks: How Much Time is in Your Day?     I have a different take on the situation.  The metric that she is describing is related to estimation, but estimation should not contemplate duration, only effort.  So my estimate for a task ought not vary based on my availability to do work, as the task could be assigned to another available resource.  However, my "velocity" does vary from week to week, and in fact from day to day.  I submit that VELOCITY is the amount of work that you get done within a specific period of duration.  This period can be measured as a day, a week, or a month, depending on how frequently you measure.  

There are several cool things about measuring velocity, separate from effort and duration.

1. You can capture velocity at an individual or group level by simple aggregation. (This does not work for duration based estimation and scheduling.
2. You can measure velocity along multiple vectors (or projects, milestones, or deliverables).  That is, you can build a resource to work vector matrix to see how fast work is progressing along multiple paths.
3. You can capture historical average velocity of resources or teams, to use to project duration into the future.
4. You can use historical average velocity to validate work commitment - that is, if a resource averages 3.5 effort days per week (velocity) based on his own estimates, then when he commits 6 effort days, you can assume that he will need to work 70 hours to complete.  These conversations about commitment and realism have amazing affects on peoples ownership of their estimates and commitments.
5. You can plan different velocities around variable cycles (holidays, special events, or vacations).  

Perhaps the coolest thing you can do with velocity metrics is to recognize how much time is spent on NON-DELIVERY VECTORS.  A non-delivery vector is a fancy word for work that you do that does not align with a specific project goal.  Team meetings, staff interviews, staff training, coordination and status meetings don't count towards delivery.  They are not "tasks" that should be captured in a project plan.  My team calls them "things".  There are other types of "things": helping a team mate solve a problem, having a design meeting, one-off discussions and phone conversations, reading e-mail, responding to e-mail.  All "things".  

The following ideas have been discerned by measuring in this way:

1. People in leadership roles (whether formal or informal) usually have more things than non-leaders.
2. People who deal with uncertainty (analysts, designers, project managers, etc.) usually have more things than people whose work is more deterministic.
3. People who have administrative responsibility usually have more things (build master, source librarian, etc.) than those who are largely project bound.

More "things" means lower velocity.  The resources that I observed having the highest velocity were those who had more repetitive tasks: testers, report developers, database dml developers.  I believe that offshore developers working to specifications, should (in theory) work at very high velocity because they are typically heads down, low collaboration.

At first this was difficult for me to take and understand as a manager.  Here is why:

1. I had a team that was very heavy with contract staff, including some of the leadership.
2. My incentive was based on budget versus time frame (so people delivering less feels really bad).
3. My smartest most capable people, appeared to be my least productive (how can this possibly be).
4. As soon as I assigned someone leadership responsibility, his output was cut in half.

It is the same sort of reaction most people have when they first try to have some discipline around their household budget.  They are incredulous about the way they actually spend money, as opposed to the way that they perceived they were spending it.  I had a similar reaction to the way I was spending resources as a manager.  I had to stop looking at the individual velocity and focus on the aggregate velocity.  Having the brightest guy doing all the work may give 2-3x more velocity for him personally, but having the output of 4-7 people double because of his direction is better.  Being able to bring additional staff to bear because the leadership structure and knowledge transfer capability is there is worth more long-term, than a marginal increase in velocity, it means that I can add resources efficiently (without significant drag) because the team's infrastructure is able to support it.  

Having the data to understand how your team really works means taking the irrelevant data and fiction out of your estimates.  Duration based estimates always contain an element of irrelevancy or fiction, because they can't factor out the effort that doesn't contribute to the specific delivery vector.