This is an old revision of the document!
With SmartDirt 1.0 completed (December 2011), we're over due to analyze the measured results of the SmartDirt team. This page will summarizes the actual SmartDirt effort and durations, and computes the teams velocity. Velocities can be used to calculate estimates and predictions of future projects.
First, the raw data:
| Story | Estimate (ideal days) | Measured | Effort Velocity | Calendar Duration | Calendar Velocity |
| 0 | 8 | 4.25 | 1.88 | 2 | 4.00 |
| 1 | 26 | 30 | 0.87 | 31 | 0.84 |
| 2 | 44 | 42.1 | 1.05 | 35 | 1.26 |
| 3 | 51 | 57 | 0.89 | 35 | 1.46 |
| 4 | 37 | 99 | 0.37 | 29 | 1.28 |
| 5 | 65 | 32.5 | 2.00 | 140 | 0.46 |
| 6 | 26 | 27 | 0.96 | 60 | 0.43 |
The following charts show the velocity as measured for the development duration of the project. The first chart shows the estimates of stories (in ideal days) and the measured duration (in actual days). If the team is “hitting it's mark” the two numbers will be identical for each story (variation between stories is due to the actual technical content of each story).
The second chart shows the velocities of each story, as measured in actual task work days, and as measured against the calendar. The first velocity is called the “Effort Velocity” (EV) while the second is called “Calendar Velocity” (CV). In general velocities are applied to story estimates to predict actual end dates. An Effort Velocity allows you to calculate the actual task days, while the Calendar Velocity allows you to calculate the story completion date.
If all work was homogeneous throughout the project the velocity numbers shouldn't vary much from story to story. This is, of course, not how the world operates and the SmartDirt project was no exception. There were several interruptions on the project which took one or both developers away from core coding for extended (months) periods of time:
- New License System
- ADF Converter work
- ADF Implementation and rework
- Vacations and Holidays
The Effort Velocity does not take this into account because we didn't record specific tasks for “developer doing something else”. On the other hand, Calendar Velocity does take this into account because it only looks at start and end dates compared with estimated work days. Calendar Velocity also takes into account weekends. Because of this Calendar Velocity is ideal for applying to stories or projects to get a more reasonable expected end date.
Summary Velocities It's not reasonable to use any specific velocity from any one story, but it's better to compute aggregate velocities over the entire 1.0 project. The aggregate values will lump many real world distractions in and do a better job of modeling future performance. Average V incorporate all distractions encountered on during SmartDirt 1.0, while median V only take into account moderate distractions (multiple month distractions are thrown out).
| Average | Median | |
| EV | 0.88 | 0.97 |
| CV | 0.82 | 1.06 |
NOTE: Story zero was thrown out of the data calculations because it was so short and wasn't technically similar to the other stories. The artificially high velocities skews the average and median values to higher than actual.
How to apply. For future projects planning can use these numbers to calculate more likely end dates and durations on a story by story basis or the entire project. For example suppose a story is estimating 37 ideal days, using the average EV, we can compute probable duration = 37 / EVa = 42. This tells us the engineers are probably going to “run over” by 5 days on the original estimate for the story. Using the average CV we see an end date of 37 / 0.82 = 45.1 or probably 46 days in the future.
Example 2: SmartDirt stories total to 257 ideal days, slightly more than one work year. With two engineers we'd expect it to be done in about 6 months, which didn't happen. A more likely date would be 257 / CVa = 313 days. In fact the actual end of SmartDirt ended up being
Caveats The following conditions, if encountered, invalidate the use of these velocities:
- Major changes to team - changing engineers. The team isn't big so any change is significant.
- Major new technology introduced - e.g. NDK on x86, 'porting to Windows Mobile'.
- Borrowing (poaching) engineers for other effort - Will invalidate Median V numbers.
- The small number of stories mean that the median values aren't in any sense typical.
Future Planning The current velocity numbers should be used to compute more likely dates for communication to management or internally to decide if specific work can be done within a specified time frame. Future projects should continue to measure velocity and in particular add to the data so median calculations are more statistically reliable.
