Home arrow Blogs arrow Plan and Deliver arrow Simple Math
Simple Math PDF Print E-mail
User Rating: / 0
PoorBest 
Written by Peter Schuh   
Tuesday, 24 July 2007

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:
  1. ahead of schedule (our Historical Velocity is greater than out Required Velocity),
  2. on schedule (Historical Velocity = Required Velocity), or
  3. 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 (2)add feed
PeterSchuh: ...
Hi Quinn-

After completing the third paragraph to my answer to your question I decided it was better to post it as a complete blog entry. Please have a look at "Setting Goals for Success" and tell me what you think. It should post shortly.

Thanks for the question!

-Peter
1

August 04, 2007
Quinn: ...
So what do you consider the highest standard to use to gage a successful iteration. Our company seems to dwell only on completion of stories the team has committed to for the iteration. Of course we get side-lined by an occasional production support task or a overly optimistic lead developer that bits off more than we can chew.

I feel that its a huge slap in the face when you are programming like a ferret and dont get to 1 or 2 stories out of 25-30 in a 2 week iteration and the PM or IT Director is "disappointed" that you have carry over.

Our velocity is great, our burn down is good ( steady slope ), we just miss 1 or 2 stories every time...and thus I bring the question to you...what is the TRUE measure of success.

For me I feel its not "DID YOU COMPLETE ALL THE STORIES" response. Maybe I am wrong but the developers are not feeling good about the great accomplishments they do have completing 90-95% of the stories they commit to...

Thoughts or Feedback would be great !
2

August 03, 2007
Write comment


Write the displayed characters


busy
Tags:
Click to add your tags...,
 
< Prev   Next >

Video News

ThoughtWorks Mingle 2.0
 
Copyright © 2006 - 2008 CMC Media, Inc. All rights reserved. All marks are trademarks of CMC Media Reproduction in whole or in part in any form or medium without the express written permission of CMC Media, Inc. is prohibited  
 
 CM Yellow Pages | ALM Expo | CM Today | Configuration Management Journal | CM Crossroads