I'm currently using Planning Poker to do our detailed estimates. This works great but relies upon a fairly detailed work breakdown. Often it takes 6-8 weeks to get a sufficiently detailed design and work breakdown.

I've found the 6-8 weeks of analysis are often wasted as the estimate comes out so high it doesn't make economic sense to continue the project. I think providing a high-level estimate up front with a wide range might be better to weed out these shaky business cases.

What tools and techniques exist for high-level initial estimates?

Right now I just pick a previous project that "feels" the same and provide a -50%/+100% range.


3 Answers 3


If you are doing detailed planning poker sessions for all of the requirements up front, you are wasting a lot of time, as in my experience, detailed project requirements simply aren't that fixed, so you spend a lot of time estimating items that you never build, or are so greatly changed by the time you build them that the initial estimate is not valid.

All estimates are guesses, but you can get better at estimating if you do it often and keep data about how accurate your estimates are. Estimation is best done at two levels, once initially on the project and another as an ongoing process within the project.

First, when asked for a project estimate - estimate at the feature level, using your experience on previous projects. Keep the data on your previous initial estimates and see how you track against them. You can do this initial estimate similarly to planning poker, but don't break the work down into tasks. Simply give yourself some big buckets (increments of a half week or week for the features could work, but not much more granular than that) to estimate. If more than one team member is estimating, don't waste time on too much discussion at this point, just go with the most pessimistic estimate rather than getting down into the weeds.

Second, as you work through your short project iterations (assuming that you do have short iterations), you pick the highest priority items and estimate them at the task level (and of course develop and deliver them). Once you've cycled through that first iteration you can see how accurate your detailed estimates are, as well as how they compare to your initial ballpark estimates. Now you can revise those initial estimates as you see how accurate they are, and once you have a few cycles under your belt you can give a confidence interval for the project completion date.

The units for the ballpark estimate are a good communication tool for the precision of the estimate. Your initial units are in days or weeks, but your detailed estimates are in hours.


Estimation for everything generally starts by breaking it down.

Get as granular as you can, even if that's only to the level of major features, and estimate those. Even at that level, you can still use a planning poker meeting (or any other consensus-based estimation method, for that matter).

There's also some formulaic estimation systems out there (COCOMO comes to mind), but I personally don't put much stock in them.

  • +1 for granularity. I actually supply the granular list with a financial estimate on each line, so they can see that the big number at the end is indeed made up of many small and reasonably priced tasks.
    – Fenton
    Sep 18, 2010 at 10:12

We do this by creating two tasks instead of one:

  1. a task to estimate work to be done
  2. a task to actually do the work (within the estimates made)

You can estimate the first with poker, and, after the "long" estimation is completed, you have enough information to estimate the second.

Yes, sometimes it results in conclusion that this work is too expensive to be done. But unless you actually spend work on its estimation, you can't know it anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.