There are countless bottom-up and top-down estimation techniques, and most of them do not require you to have a team.
Top-down techniques estimate by analogy. You can compare the proposed project with similar past projects, and use this experience to come up with an estimate.
Bottom-up techniques split the project into small work items that can be estimated individually, and then add up all the estimates.
All of these are fatally flawed.
Unless you have a wealth of experience, top-down techniques are unlikely to account for the variance between projects. Unexpected events turn up and can throw an estimate off the rails. There are techniques to compensate and account for that (such as by inflating estimates and adding slack time), but in the end you are taking a guess on how to fudge the guess.
Bottom-up techniques can produce very reliable estimates, but require a ton of advance work. In particular, the project must already have clear requirements and a high-level design so that you can estimate individual components correctly. The estimate is only as good as the level of detail as the analysis.
I once did such a function point analysis / COCOMO as a homework exercise and found that the resulting estimate was way too low when compared with a back-of-the-envelope top-down estimate. Upon checking my work, I found that I had failed to go into sufficient detail – FP analysis touches on every single input field, every single database column, every single API paramter. If you glance over that, your estimates will be off.
Another drawback of FP analysis is that empiric conversion factors are only available when analyzing a form-based database application (also note that this technique predates relational databases) …
You likely don't have time to do a full bottom-up analysis. It would therefore be most sensible to individually estimate the work items you already have, in a metric such as person-days or person-weeks, e.g. “my past team of 5 people needed two 2-week sprints for a similar epic → 20 person-weeks”.
- Use your actual experience as far as possible.
- Don't make the estimate too detailed and paint in broad strokes. If in doubt, round upwards.
- Decide whether you will base your estimates on “this should only take a week” vs “this typically needs two weeks”. Depending on that you should pad your estimates with time for meetings, holidays and other overhead.
- Add up your estimates. Decide whether you need a buffer for unexpected developments or release testing.
- Don't report a single number, report a range of feasible numbers. For example, estimate an upper/lower bound for each item.
- Keep general quality requirements in minds for your estimates. A quick and dirty prototype can be hacked together within a few weeks, whereas a highly reliable software needs to spend more time on communication, documentation, reviews, debugging, QA, and so on. Compare also the 15 COCOMO factors.
Because useful estimates are difficult, agile techniques tend to reduce the use of estimates, or at least the scope of these estimates: it is easier to estimate small tasks that can be done within a day, and it is easier to estimate things that are less than a month away. While your estimates can give an idea for the general scale of the project, be prepared to update the actual schedule over the course of the project.
