I received a couple comments on my post about Prioritizing SaaS Features.  One comment was focused on the use of EV and AC which I will address later, the other was on the use of Ideal Hours.  The comment on Ideal Hours was from Rob Park, an Agile Coach from Colorado.  Here is an excerpt from Rob’s comment:

The one thing I feel is optimistic about your calculation is the ideal hours though. Ideal hours are not actual hours, so I think you need another factor in there to convert to actual hours based on actual velocity trends.

Great point Rob!  While Ideal Hours are not representative of Man Hours, there are a few tools I use to try to get them as close as possible i.e. the conversion factor as close to 1 as possible.  First, team members sign up for tasks and estimate as part of the iteration planning and decomposition process as discussed here.  Second, estimates for specific team members are tracked against actual time as discussed here.  This gives us our margin of error for a specific team member that we can use to size our buffers.  Third, we use the process described here to evenly load the work onto the team for the iteration. Finally, if tasks change hands during the iteration, estimates and cost curves are adjusted accordingly.  This may cause an item(s) to get descoped during the iteration and technical debt to increase, but this hopefully will be addressed as part of the next iteration.

So why not just use Man Hours?  I like the concept of Ideal Hours because it gives you more flexibility on estimates.  The term Man Hours has rigid foundations in project management that do not work well in the Agile world.  Think of it this way.  With Ideal Hours we try to approach real Man Hours and use a factor to determine how right (close) we are.  With Man Hours we consider estimate accuracy a measure of how wrong we were.  Ideal Hours just fit better into Agile thinking.