Planning Software Development using Feature Dollars

If you’ve ever worked on a software development project I’m sure that you have been involved with the arduous work necessary to determine what features to build. It is definitely not an easy task. There are a number of factors to consider: 1) Expected Release Date; 2) Budget; 3) Resources Available and their associated cost.

Using the concept of “Feature Dollars” can help simplify this process while empowering the Owners to customize the system to their exact needs.

Let us first begin by defining “Feature Dollars” (FD). An FD, simply put, is a unit of measure. Just as a US Dollar has a perceived worth so does an FD. (ie. A book is worth $15; a login screen is worth 10 FDs.) The actual worth of the FD is determined by a number of factors specific to your project that we will explore in this article.

When you build something, anything, you must use some resource as your primary material in the construction of the “thing” you are building. When you build a home the resources used are wood, concrete and brick. When you build a car the resources are steel and fiberglass. When you build software the primary resource is people’s time or person hours, as we will refer to them here. A person hour is a unique resource. Because the resource is temporal it can not be “warehoused” or saved if it is unused. When an hour elapses that hour is gone forever. This is one of the reasons that software construction estimation is so difficult.

Time Box

Realizing that time is our biggest enemy most of us create a time box or a time budget to limit the amount of time that we can afford to allot to the construction of the software. To create our time box we will use the following equations:

Time box = ((# of Developers * 8 hrs/day) * # of days available) * % effective

# of Developers = The total number of developers committed to your project. This is the most flexible value in the equation. Most of the other values can not be changed.

# of days available = The number of working days between the start of construction and your release date.

% Effective = The percentage of time during any given day when a resource is productive on your project. I like to use 70% as a baseline.

Let’s plug in some numbers to generate a sample time box.

Time box = ((5 * 8 hrs/day) * 105 days) * 70%
Time box = (40 hrs/day) * 105 days) * 70%
Time box = (4,200 hrs) * 70%
Time box = 2,940 hours

Our example assumes that your project budget was set appropriately to allow for 105 construction days for 5 people at their hourly rate. If you are dollar constrained rather than time constrained you can first determine the number of hours that you can afford and back into the # of days available. Here is the equation for determining your number of available days.

# of days available = (Budget dollars / Avg. dollars/hour) / (# of Developers * 8 hrs/day)

Budget dollars = Construction budget in dollars.

Avg. dollars/hour = Average hourly rate for all resources working on the project.

Construction Estimate

With our time box calculated we can now focus on establishing our construction estimate. An accurate construction estimate is vital to the success of the construction phase of the project. Therefore it is worth putting some significant effort into creating this estimate. Determining the construction estimate is out of scope for this article. I’m sure there have been volumes written on determining accurate construction estimates so I will not try to repeat that work here. For our purposes here you will need to know each feature of your system, the effort required (in person hours) for each feature and the dependencies among the features of your system.

Scaling

We have our time box and we have our construction estimate. We are now going to scale these items and turn them into feature dollar values. By scaling these values we reduce the precision of the values. By reducing the precision of these values we are automatically creating a buffer of time for the project. I’ll demonstrate just how this buffer is created in a moment.

Scaling the Time Box

To scale the time box we will multiply the person hours by the average hourly rate for our resources and then divide that number by our scale. In my example I am using 100 as the scale, however, you can use any value that you see fit. Whatever you select for your scale be sure to use the same value when scaling the time box and the features. Here is an example:

(2,940 hrs * $80/hr) / 100 = 2,352 FD

Scaling the Features

To scale the features we will do something very similar. For each feature we will take the effort estimate and multiply it by the avg. hourly rate. Then we will divide that amount by our scale, 100. For instance, a system feature estimated at 22 effort hours at an avg. hourly rate of $80/hr would cost $1,760. When we divide that by 100 we get 17.6. We will then round this value up to the nearest whole value. So our feature costs 18 FDs. By rounding up to the nearest whole number we are building in a little bit of buffer just as I mentioned earlier.

Determining What to Build

We now have our time box and all of our features expressed as Feature Dollar values. We can now turn this information over to the system owners and allow them to select the features that they would like to include in the system. The best way to do this, as I have learned, is to list all of the features and their values, and the system’s feature dollar budget on a spreadsheet. Additionally, you will need to indicated which features are mandatory and if features are dependent on other features.

Empowered with this information the system owners can select the features that will benefit them the most. Of course they are likely to argue about how you arrived at these estimates, the budget and other aspects of the project, they wouldn’t be real system owners if they didn’t. However, you’ll have confidence in your estimates and you’ll have confidence in your process. You’ll be able to justify all of your figures and most importantly you’ll have given yourself a fitting chance to deliver a system that will benefit its owners.

Summary

The keys to making this work for your project are:

• Accurate Effort Estimates
• Scaling the Time Box and the Features
• Identification of Dependent Features
• Selling the Concept to the System Owners
• Empowering the Owners by Allowing them to Select the Features to Include

I’m certain that this idea may not be new to many of you. I’m also certain that much of this has been borrowed from other processes. I certainly don’t claim to have invented any of this information. Additionally, I know that there are other approaches out there, such as XP, which propose to do things drastically different. I’m glad there are other ways to do this out there and I hope that you would not try to force fit this into a place were it would be destined to fail. What I do hope is that I have presented some things for you to think about, comment on and hopefully use to your benefit. By sharing this information with a broad audience I am also hoping to find ways to improve this process. Please post your comments and criticisms so that we can all benefit from the sharing of this information.