Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

Prioritizing SaaS Features – More on Ideal Hours

clock July 30, 2009 09:05 by author Chad Albrecht

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.



Prioritizing SaaS Features

clock July 29, 2009 06:14 by author Chad Albrecht

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.

image

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.



An Alternative to Story Points - Ideal Days

clock July 14, 2009 11:42 by author Chad Albrecht

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:

image

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

image

Figure 1 – CVP vs. CVE

image

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?



About me...

bio_headshot

I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster

MCTS

Calendar

<<  August 2014  >>
MoTuWeThFrSaSu
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Blogroll

Download OPML file OPML

Sign in