Is there a good reason to make time estimates for features that are months out?

Question

I was in a meeting today with a consultant (consulting us on internal procedures) and we went through an exercise of planning out the next three months of development. I'm not opposed at all to doing this, I think it is essential to have an understanding of what is coming next, in what order, and their relative magnitudes. I also think it is great to set goals for what you'd like to get done by certain dates. But I've always thought, to the disagreement of this consultant and some of my team members, that trying to put time estimates (even loosely in days and weeks) on implementing features (that have not been spec'd out, or even discussed at length) is a completely pointless and futile task. In my experience, by the time I get to working on it, the feature will have changed drastically or involve so much more than I could have known.

Am I off base and missing the value in spending time and energy coming up with a guess that in 2 months it'll take 8 days (taking into account HL) of my time to implement FeatureX?

Answer 1

It's completely reasonable to discuss how much that feature could take. This improves understanding of what should be thought of more carefully and what should be discarded immediately. Management needs this to plan better and decrease the chances of the product being late or incomplete.

However it's important not to fall into the trap here - you could say "well, it could take N days" and then three months later after the feature has been inflated greatly the management will tell you "you promised that it would take N days, how dare you increase the estimate and demand 4N days now?" You need to document that this is a very distorted estimate since you don't know the feature size completely yet.

Answer 2

Yes, I would say you are missing the point.

Maybe and analogy is in order... You are doing some home rennovations, you come to me for an estimate of my work. I ask you what you want done, you tell me. Then I come back with a quote. I tell you "well, I know what I will get done next week, but from that point it is going to get a bit fuzzy... I really don't think there is any value in me being specific, but I am sure in a few months/years/whatever it will get done, but as long as you keep paying me, I am sure I can figure out what to do."

Would I get the job?

Answer 3

When dealing with loosely spec'd requirements, as well as when dealing with items that are months down the road, it is often useful to give High Level estimates. A High Level estimate could be represented as a wide range (ie 4 to 8 weeks). They are useful to provide the receiver of the estimate a rough understanding of the size, allowing them to perform some planning. The contract surrounding the High Level is that it will change when you are required to provide a more accurate estimate. The lower level estimates usually get narrower, and within the range you originally provided. You would need proper specs by this point, and a better understanding of your available resources, which is most likely not available months before implementation.

Answer 4

It really depends on what the estimates are going to be used for and what expectations are attached.

If the estimates are used to report to management without a caveat then this can be a dangerous practice. If on the other hand they are used to do some high level planning or draft a project plan for discussion, then these estimates can be extremely useful.

We often use the term WAG (wild arse guess) for these type of estimates. They come with a possible +100%/-50% variance. As the requirements get fleshed out this estimate is moved to a Ball Park Estimate which has a possible +50%/-50% variance.

Answer 5

I think you misunderstand why you are asked for those estimates.

Lets say you have features A, B, C, D and E, which you want to implement in that order. You estimate each of them to take about one week. Your management does not want to know if you will need one week to implement feature E one month from now. They want to know if your project will be finished on time. If there are delays, they want to know as early as possible, so that they can take action to bring the project back on track. So they ask for your estimates, which not only gives them an end date (however uncertain it might be), but also the milestones for Feature A, B, C and D. Now they can see easily if the project is delayed or not by checking if you met the milestones

That's why they want it.

That being said, Joel said in one of his articles that a detailed schedule makes you think about the design of the modules in advance, leading to a better thought through architecture of the software.

That's why you should want it, too.

---

Edit: Well, maybe I misunderstood your question ;-) If you have no clear specification of the features, you can't estimate, you can only guesstimate. The value of which is rather low. My advise would be to steer the next meeting from those guesstimations to a clearer specification of the features. Try to engage them in a conversation about the more specific details of the functionality.

Don't expect them to come up with detailed feature specifications. If they don't have those, it is your job to provide them (and on that base, give some time estimates).

Answer 6

It’s like predicting weather on an exact day six months from now: you don’t know what it’s going to be but you will be able to say what is going to be like. And based on the assumptions it’s possible to look ahead and roughly estimate the heating or air-con bill, plan the wardrobe, book holidays and invite friends over.

Now predicting software development is somewhat different from predicting weather in a sense, that as programmers we have much more and direct influence on building software than weather: we can add and cut features, prioritise and sometimes even flex resources.

By having a somewhat realistic goal the team is aiming to achieve in three or six month time its possible to work backwards and figure out all the things that have to be done to get there. And then estimate the tasks and indulge in cutting features, setting priorities and moving resources around. At times it can be very revealing and surprising how having a clear goal in three months time affects tasks and priorities of what needs to be done tomorrow or straight away.

Do we need to find more customers? Or start looking for more people right now? Should we be cutting features or should we become more ambitious in our plans? Can John take two weeks annual leave in two months time should we be looking at introducing an extra developer now, as a cover for John once he is off holiday?

Developers hate frequent task switching and last minute projects, by having a clear roadmap with some resource assigned you’ll help developers feel more secure and prepare for future projects.

Answer 7

The best book I have read on managing the software development process is Rapid Development by Steve McConnell. This covers the issue of estimation in great detail - if you are involved in project planning and you haven't read this book, I doubt you really know what you are doing (I didn't).