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.
I’ve talked about using your Value Proposition(VP) to rank features by dollar value here and using Ideal Days to estimate duration here. Now let’s combine the two and look at total value based prioritization of features or PBI’s. In essence what we are doing is giving the highest rank to features that will yield the most value in the least amount of time.(cost) To calculate cost we will need some measure of cost per hour. If you have the actual numbers, use them, if not here are some tools you can use. Work hours in a year: 2080 Annual salary: $50K=$24/hour $100K=$48/hour. Margin for overhead: 20-30%. With these tools let’s assume that our team makes on average $90K annually. This gives us $43 an hour. Adding 25% we get about $54 an hour. From here we can simply multiply our cost per hour by our Ideal Hours to get total cost per feature. Subtract our total cost from our value (sales) and we get the profit per feature. We then prioritize (rank) by profit.
|Feature ||Rank ||% of total ||Value ||Estimate (Ideal Hours) ||Cost ||Profit |
|8 ||1 ||5% ||$ 4,902 ||2 ||$ 108 ||$ 4,794 |
|9 ||1 ||5% ||$ 4,902 ||2 ||$ 108 ||$ 4,794 |
|2 ||1 ||5% ||$ 4,902 ||4 ||$ 216 ||$ 4,686 |
|1 ||1 ||5% ||$ 4,902 ||8 ||$ 432 ||$ 4,470 |
|3 ||1 ||5% ||$ 4,902 ||8 ||$ 432 ||$ 4,470 |
|6 ||1 ||5% ||$ 4,902 ||8 ||$ 432 ||$ 4,470 |
|7 ||1 ||5% ||$ 4,902 ||8 ||$ 432 ||$ 4,470 |
|11 ||1 ||5% ||$ 4,902 ||8 ||$ 432 ||$ 4,470 |
|4 ||1 ||5% ||$ 4,902 ||16 ||$ 864 ||$ 4,038 |
|5 ||1 ||5% ||$ 4,902 ||16 ||$ 864 ||$ 4,038 |
|10 ||1 ||5% ||$ 4,902 ||16 ||$ 864 ||$ 4,038 |
|12 ||1 ||5% ||$ 4,902 ||16 ||$ 864 ||$ 4,038 |
|16 ||2 ||4% ||$ 3,922 ||4 ||$ 216 ||$ 3,706 |
|17 ||2 ||4% ||$ 3,922 ||4 ||$ 216 ||$ 3,706 |
|13 ||2 ||4% ||$ 3,922 ||8 ||$ 432 ||$ 3,490 |
|14 ||2 ||4% ||$ 3,922 ||8 ||$ 432 ||$ 3,490 |
|15 ||2 ||4% ||$ 3,922 ||8 ||$ 432 ||$ 3,490 |
|21 ||3 ||3% ||$ 2,941 ||2 ||$ 108 ||$ 2,833 |
|22 ||3 ||3% ||$ 2,941 ||2 ||$ 108 ||$ 2,833 |
|18 ||3 ||3% ||$ 2,941 ||4 ||$ 216 ||$ 2,725 |
|23 ||3 ||3% ||$ 2,941 ||4 ||$ 216 ||$ 2,725 |
|19 ||3 ||3% ||$ 2,941 ||16 ||$ 864 ||$ 2,077 |
|20 ||3 ||3% ||$ 2,941 ||16 ||$ 864 ||$ 2,077 |
|24 ||4 ||2% ||$ 1,961 ||8 ||$ 432 ||$ 1,529 |
|25 ||4 ||2% ||$ 1,961 ||8 ||$ 432 ||$ 1,529 |
| || || ||$100,000 ||204 ||$ 11,016 ||$ 88,984 |
As you can see this moves our prioritization around a little bit. The nice thing about the above is that we can automate it. In your Agile Management System each feature should accept a VP rank and an duration estimate in Ideal Hours. You will also want to have a mechanism to enter the Value of the release, $100K in the example above. Using these inputs your system should be able to auto-prioritize your features for you. Now that you have cost, you can track EV,PV and AC on your CVE vs. CVP graph. I don’t like the PMI term “value” in the EV and PV metrics. Their old names used to be Budgeted Cost of Work Performed(BCWP) and Budgeted Cost of Work Scheduled(BCWS) which I think is more fitting. Either way, don’t confuse the term “value” in these metrics for revenue. The value they represent is the cost, i.e. the value of the work. For this example, we will assume that the estimates were correct and AC and EV are equal, that is, there is no cost variance during the release. The graph would be similar to that of Figure 1.
Figure 1 – CVP, CVE, PV, EV & AC
I know there are some hard-core Agile managers out there who believe that we should not concern ourselves with revenue estimates. Some think that simply managing costs while we continue to iterate is enough. If you are of this mindset, let me ask some questions. How do you know when your costs are nearing your sales? How do you determine if your project will be profitable? If given multiple projects to work on, how do you choose the most important one?
I would also like to remind you that I have not taken risk into account yet, which will again change the priority of the features. I will try to cover this in future posts.
As always, I would love to hear your thoughts on this.
I have tried using Story Points as part of my Agile estimating sessions and found them to be problematic. Some of the problems include:
- Introduce more complexity through the use of a unit-less measure.
- Lack of business clarity when using story points in discussions with other executives.
- 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?