How long will it take

From WackyWiki

First you need to understand where the question comes from. Usually it’s a sales or business type person who wants to know how much it’s going to cost them to get a solution, and how likely it is to come in on time and on budget. They want to give commitment that they can add value to the clients business by a certain day. This value comes from a part of the functionality of product X. And if the cost of product X is less than the business value, it’s a sale.

Product X has a lot off additional features; a lot of these will never be used. This leads us to a very important question: “Where’s the value?” Break down product X into features that add value to the customers business. Anything that doesn’t should be stripped (or at least be postponed till the rest is done). Now that we split the product into value-adding features we got more manageable chunks and we know that it’s less likely that we’re putting effort into a feature which isn’t going to be used.

Ballpark estimating is the next step; start with the features, are they larger than a breadbox and smaller than a house? Examine each feature briefly; is it easy or hard to realize? Are there any risks, blind spots or uncertainties? Is there stuff that needs to be checked out first, anything optional? Take this info and sort the features by priority; highest business value and risks first, blind spots and options last. Arrange those features into sets of about a month. This all will give you an overall idea of the scope of product X and an initial release planning.

If you haven’t talked to the business guy and the customer already, gather your guts and prepare to. Tell him about the feature-sets you defined, how long the sets will it take, and how confident are you about that number. Explain the risks you identified, what their impact could be and what needs to be done to avoid it. Make it very clear to him that, given your release planning, feature-sets planned for later have less business value and have a bigger uncertainty associated with them.

Suggest to do the first set and, after delivery, talk about the next and if it’s still ‘correct’ or it requires some additional features. This way you’re adding business value right away and are giving the customer room to gather his thoughts and redefine or fine-tune the requirements. The alternative is a big requirements up front (BRUF) approach with a change management process which strives to avoid "scope creep" throughout the project. Something which we all know will fail because the requirements are never complete or clear and the customer always comes to new insights.