There is a simple equation that is the basis for most of the planning and tracking calculations I use with projects and teams. One permutation of this equation--for calculating Velocity--is well-known to many Agilists. This common permutation can be expressed as: v=e/t or Velocity (v) = Effort (e) / Time (t).
Casual readers beware. As advertised above, this blog entry uses math.
Also, I'll be focusing on practical theory, leaving untidy reality as a discussion topic for a later blog entry.
Comparing Velocity to Speed
The velocity equation is most simply explained by comparing it to another better-known equation: s=d/t or Speed (s) = Distance (d) / Time (t).
In the speed equation, Time is a duration such as years, hours or seconds. Meanwhile, in the velocity equation, Time is a duration unit or timebox such as a release, an iteration, a sprint or a task cycle. Distance is a metric or imperial measure, such as miles or kilometers. Effort is a measures of effort for a single individual, such as Effort Days (my preferred unit), Ideal Days, or Story Points. Finally, speed measures the distance traveled in a given time period while Velocity measure effort completed in a given time period. The two equations, like the terms themselves, are nearly synonymous.
The Value Principle Behind Velocity
The equation v=e/t computes required or actual velocity. For example, I can use a project team's historical average velocity (measured in effort days per task cycle) to determine whether they are on target to complete their current project. First, I obtain the project team's historical average velocity using the following equation:
Historical Velocity (v) = Effort Days Completed (e) / Task Cycles Completed (t)
The output of this equation tells me the velocity (effort days completed per task cycle) I can expect from this team, assuming all other factors are equal. Next, using the same equation with different inputs, I can derive the velocity required to complete this in-flight project:
Required Velocity (v) = Effort Days Remaining (e) / Task Cycles Remaining (t)
By comparing the outputs of these two equations, I know whether my project team is:
- ahead of schedule (our Historical Velocity is greater than out Required Velocity),
- on schedule (Historical Velocity = Required Velocity), or
- in need of help (Historical Velocity < Required Velocity).
Comparing these outputs tells me whether we have time to give freebees or whether I need to be negotiating out scope or asking for additional resources.
Beyond Velocity
But this is only the beginning of the fun we can have with v=e/t. By using other permutations of the equation we can get a variety of useful outputs.
We can use t=e/v (Time = Effort / Velocity) to make quick scheduling and resourcing calculations on anything from small feature requests to multi-year projects. You should use an average velocity forecast per resource (such as 3 effort days per task cycle). Also, remember that a task cycle equates exactly to one calendar week. There are many possible inputs for the above equation, and the outputs can be quite powerful and useful. Here is the same equation with more description:
Task Cycles Required (t) = Effort Day Estimate (e) / Average Velocity of Individual or Team (v)
Finally, we can use e=t*v (Effort = Time * Velocity) to calculate individual or team capacity. I use this equation regularly for planning iterations or releases. It tells us how many effort days we can complete in a given time period, such as a release or an iteration. We use this number either internally or with the business to plan the correct amount of work into one of these timeframes. Here is the same equation with more description:
Total Effort Days Available (e) = Number of Task Cycles (t) * Average Velocity of Individual or Team (v)
Apologies, again, if this blog comes out a little dry. I tried to turn it into a comic strip and nearly broke my hand.
Comments 
Write comment
 |
Show/hide comment form