2

Here's my dilemma... I need to provide a rough order of magnitude estimate for development time of a system that we know the requirements (story map created) however we don't yet have a technical team in place to do the work. The issue is this, before hiring the team, management wants to know how long it will take to build. I created a story map and have identified all known product themes and epics but don't know how I can determine a ballpark estimate (e.g. 18 months, 24 months, etc) since I don't have a team(s) in place, haven't written stories, obviously don't have LOEs for stories, and don't know my non-existent team's velocity.

How can I best provide an educated estimate? My time constraint is one week.

2
  • 4
    The real question should be, how to tell management they have very unrealistic expectations. But that's a workplace issue, way better suited for The Workplace. – Doc Brown Mar 10 '19 at 14:53
  • You don't. I agree with @DocBrown. Getting this estimate even roughly right is much more a matter of luck than of experience/skill. You won't be doing the work, others will. Estimating for someone else is like guessing what food they like. It's pointless. – marstato Mar 13 '19 at 9:42
7

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.

-1

Go off previous projects you have run.

Identify parts of the new project that are similar to other things and use the time it took for those thing to complete as the estimate for that part of the new project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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