I have tried using Story Points as part of my Agile estimating sessions and found them to be problematic.  Some of the problems include:

1. Introduce more complexity through the use of a unit-less measure.
2. Lack of business clarity when using story points in discussions with other executives.
3. Difficulty normalizing teams due to sizing baseline.

For those of you who have used Story Points, I’m sure you can at least understand the above, even if you don’t agree. 

There are a couple reasons why people want to use Story Points.  The first is to calculate velocity of a team and the second is to avoid the conversation of duration and instead focus on size of the item.  Given that, is there another mechanism that we can use to solve the issues above while still satisfying the need for Story Points?  Yes, Ideal Days with some additional metrics.

While Mike Cohn favors Story Points over Ideal Days, I am quite the opposite.  My experience has shown that if we are going to estimate things in terms of size we are better off doing so in Ideal Days.  If we use the method I suggest here and keep estimates under 16 hours then we now have a means to compare teams.  This solves problem #3 above and has been very important in the environments that run multiple teams.  Further, we can use Ideal Days in much the same way that Story Point are used.  If you use a baseline in Ideal Days along with using EBS and Proxy based estimation you can think about things in terms of size.  Your size just happens to have units attached to it now. :)  How about determining velocity?

If you attach a dollar value to each feature being developed, as I discuss here, you can now calculate some performance measurements.  If you use take concepts from both cost and throughput accounting you can calculate Client Value Earned (CVE) and Client Value Planned (CVP) to measure velocity.  CVE is the value of the completed features of the release.  Remember that we don’t realize the value of the feature until it is actually done.  CVP is simply the curve that represents where we should be from a value standpoint on any given day of the release.  Velocity is simply the ratio of CVE to time.  Here are the calculations:

A an example graph of CVP vs. CVE might look like Figure 1 with a velocity graph like Figure 2.

Figure 1 – CVP vs. CVE

Figure 2 – Velocity

You can think of the CVE graph as an inverted release burndown chart and expressed in dollar/days instead of hours.  Now if we combine this with cost accounting metrics we can have meaningful conversations with the rest of the business.  Thoughts?