Estimating Software Feature development...

I propose a different approach to software development estimation.

The first question to be asked should be:

1) When can you start development on feature X?

This question should lead to discussion and not a simple answer like "In two weeks". If you get a simple answer then ask, "Why then?" This will cause an explanation of what has to be done before the new feature can be started. This will expose the developer's priorities of work and will allow new priorities to be considered.

The second question immediately follows the discussion of the first question and is made up of two parts (so you might want to say it is really two questions).

2) Do you feel that feature X is complex and have you ever done anything like feature X before?

Notice there is no estimate of how long the development of the new feature will take. This is key. Also notice there is an estimate of what the developer is currently doing. This is exactly what is wanted. By saying when one can start working of feature X it requires one to estimate when they will finish with feature W. The estimation for completion of feature W happens after feature W has been started and thus the estimation is based on experience up to that point! I think that is great.

This brings us back to the essential nature of question 2. If question two identifies the problem as being complex, unfamiliar, or both, then you should recognize that any estimates start out as complete guesses and as experience is gained the estimates take on the form of educated guesses.

So lets go through a little example.

New Feature W: Find all customers that have purchased a monthly subscription and have canceled that subscription within two months of purchase.

Manager Lynn: Pat, when can you start on feature W?
Developer Pat: Lynn, I can start on it in 3 days.
Lynn: What happens in three days that will allow you to start on W?
Pat: I finish up feature V. All I have left to do is hook up the list control, handle the selection event and it is done.
Lynn: Okay. You've done a good job on feature V. Thanks.
Pat: Sure. That's why I get paid the big bucks!
Lynn and Pat chuckle.
Lynn: Do you think feature W is complex and have you ever worked on anything like it before?
Pat: It doesn't seem complex, but I am not familiar with the databases involved with making the queries, so I have to learn where and how to get to the data. I am pretty good with SQL so I don't think that will be a problem.
Lynn: Okay, that's good to know. We'll talk more about feature W later. Thanks.

Lynn goes away and starts to think:
"I wonder where that data is? I wonder if Pat has rights to access the data? Maybe I should ask the IT department and the DB admins about this data."

I hope this simple contrivance helps you imagine how this method of estimation works.

How can this be applied to Product estimation? Well, if the development team is working on another product then question one applies in that, "When will they be done with Product A?"

Question two still applies in that "Which aspects of product B are new and unfamiliar in concept and which aspects appear to be difficult or complex?"

I hope this "new" way of estimating software helps. This is part of what I call "Experience Driven Development". One day I will get that darn book finished!

You can do this method in conjunction with existing methods, that is, there is no rule that says you have to estimate using only one method! Use two, three, or four methods of estimation if you feel it is of value!