What's the best way of estimating initial software size using '(agile) epics', given a time-to-market but not knowing who the developers will be?

Question

Given a set of high level epics what's the best 'guestimate' we can come up with to scope the software system appropriately given a time-to-market window? What are some good/best practices for this high level estimation (I know it'll be way off, but atleast be better than "I don't know"). So we don't yet know who (i.e. which teams) would be developing this system, so we can't just drill down all stories and play planning poker with them. I'm looking for an initial and a somewhat SWAG at this level of granularity.

Here are some of the techniques and their criticisms (IMO):

• Play a high level planning poker along with tech leads in the company - have scores of 40, 80, 120 etc., Issue: No one knows what the heck they are talking about IMHO - it's easy to state whether a story is 1,2,3,5, 8 etc. but not many seem to understand the difference between an 80 or a 120 - folks would rather just go with higher estimates to be conservative (better to just guess a random number)
• Use parametric modeling tools like COCOMO or SLIM and the like. Issue - input is either SLOCs (which are just pure guesses and even more difficult with disparate technologies) or Function Points (FPs - not quite easy to do either). Although they may give good estimates as outputs, they are only as good as their inputs
• Work/Epic Breakdown Structure - I feel this is the best 'right' balance between the above two extremes i.e. breakdown epics, top-down into features to get an idea of scope. (one can also quickly come up with high-level one line stories for each feature (or if feature = story, in your case, then high-level features). Since stories usually range from 1 - 13 in the fibonacci scale (i.e., quite common IMHO to see stories in this range), just give every story/feature a score of 5 and aggregate them to get the score of the epic for a rough initial estimate (since there will be quite a few less than 5 as there will be more than 5, I feel 5 is a good mid-point/average to go by).

The last bullet method is what I'm leaning towards but am more than welcome for suggestions/inputs on what have you practiced and been sufficiently happy with and avoiding estimation paralysis - yes the estimates will be refined later on, but we still need a very high level view to balance expectations and plan accordingly :)

Answer 1

Take a look at Dynamic Range Estimation: http://itkanban.com/framework/estimation-2/dynamic-range/

It's a good technique for getting high level estimates out and visualising areas of uncertainty. Involving a couple of developers from different teams would help mitigate no knowing who will be working on it.

Answer 2

I've become a big proponent of Business Value Estimating, which is leveraged off the Team Estimation game created by Steve Bockmann. At the highest level what this does is take your user stories (at whatever level of detail they are at) and does a comparison against the other stories in the stack. Is "As a homeowner I want a color matching garage door (painting the garage door), so my house looks good" a bigger or smaller than "As a homeowner I want a front door that is safe and secure (mount a solid core door with security lock), so I feel safe" and are either of them bigger than "Put a new post in for the mailbox"?

This can be done at the product owner, technical architect/dev manager level.

Doing this rates all the stories in the project against each other. From there is very likely one or more of those stories are something your technical people are familiar with. A rough projected velocity can be factored to give you a rough schedule.

Run two or three sprints and your schedule will narrow down and become more firm.

I posted a blog that has a step by step process on playing the Business Value Game. You can find it at this link: