Rules Of Thumb For Estimating Web App Hours

Question

We all know that software estimation is difficult to get exact, but I am not looking for exact. I'm looking to be able to derive an approximate number of person-hours for a project to know how many people to hire in a startup.

So, assuming you have:

• A web application built on the .NET platform (C#, ASP MVC, etc...)
• A defined number of use cases with a mix of easy and complex ones (in this project, 70 use cases; but assume a project with a high enough number of use cases to give a good bell curve of complex and not complex)
• A defined database schema (again, in this case there are 50 or so tables, but assume a web application that does more than the typical book example with seven tables :) )
• A partner who wants a quick-and-dirty, best-current-guess estimate, and understands it's not a contract to hold, is experienced with software development, and that the software (and understanding thereof) will version and evolve
• A pool of solid, skilled developers

Do people have any rules of thumb they use to quickly guesstimate the number of hours involved?

UPDATE: I am asking for ballpark estimations rules based on measurable but coarse requirements. Answers of "4 to 6 weeks" are fun, glib answers, but I'd like to hear from people who've actually established some simple barometers of work.

Answer 1

Go with your gut then add a 3 months to it

Answer 2

It's very easy for rough guestimates to be very wrong. I would suggest breaking down the proposed app into as much detail and tasks as possible and estimating the individual tasks and adding that up. Then add in some extra time for all the tasks you forgot.

Answer 3

Hire one smart person who gets things done to get started, and then after a while, ask them how many more people are needed to finish by a given date. If you're ever not sure of whether/how many to hire, err on the side of none/one.

Answer 4

number of tables * 3 to 4 days + 6 to 8 weeks

Answer 5

I always write up a detailed list of tasks that I need to accomplish. From there, I can better judge the amount of time for those individual tasks and I add those numbers up. After that, I tack on 25-50% extra as a buffer in case of complications, which always seem to come up.

When I say a list of tasks, I mean something like this: (this is an example, be as verbose as humanly possible, especially on a site-map)

• Database
  • Tables
  • Views
  • Stored Procedures
• Sitemap
  • Home Page
  • About Page
  • Contact Form
• Migration from Development to Production
  • Self-testing
  • Customer-testing
  • Bug-fixing

I always estimate times in terms of hours. (not 15-30 minute blocks)

Answer 6

There are no rules that I would pass on. As Sam says its very easy to get these ballpark estimates wrong depending on the size and complexity of the project you are trying to estimate. Most good estimates come from some sort of iterative process where you make an estimate, look why the estimate was wrong, and then compensate next time you estimate.

Also try to be detailed when you specify the project and tasks. If you have tasks like "Do something, 30 hours" you should be cautious. I usually try to split up estimates that are larger than one work day (5-7 hours).

You also mention that you don't even know the level of expertise of the people who you are estimating for, and that doesn't make it any easier. Of course you could be extremely conservative but then you just risk over-hiring instead of running late. So I think you should ask yourself; which problem would I rather have, being late or having too many people on the project. As a startup

Answer 7

IMHO it would take approx 500 +/- 100 hours to code the app and another 300 to code the tests and again 500 to run the tests and app in the wild. so for 3 skilled and organized developers it should take about 3 months :) but it's only estimate.

Answer 8

Given that you have

A partner who wants a quick-and-dirty, best-current-guess estimate, and understands it's not a contract to hold, is experienced with software development, and that the software (and understanding thereof) will version and evolve

then can you break the project in smaller projects, in an agile manner? Decide upfront on a delivery schedule (every 3 weeks?), prioritize the use cases, time the first delivery so that you can make it, and have a loose estimation / plan on the subsequent iterations - and re-discuss priorities at every iteration. Chances are, your client will change his mind along the way anyways, so you might as well build the regular feedback/discussion in the process. It's easier to get timing right on smaller pieces.
If you can't do that, then go for Sam's option - take the time to build good estimates.

Answer 9

What you are after sounds somewhat similar to an old estimation technique called Function Point Analysis. Each requirement was identified and characterised as a type (eg. an input screen). These were then assigned a complexity rating of high, medium or low. A numeric value was assigned to the type and complexity, and the whole lot was added up to give you a function point total for the system.

You then applied a modifier to the function point total to convert it into hours effort. The modifier would take into account the tools being used and also (potentially) the skill of the developers.

The system was great in theory. The trick was coming up with the correct modifier. In practice, you would only get reasonably good estimate after you had done 3 or 4 projects, and could then calculate a modifier based on past experience.

With regards to your current project, I would suggest using a similar system, though a little simplified. Rate each table as simple, medium or complicated, and do the same for each web screen. Assign 1 point for simple, 2 for medium and 3 for complicated. Add up the total and this will be your function point total.

You then need to find a modifier to multiply this against to give you an estimate. The best way to come up with this would be to do a function point analysis on an older system developed by the same team. Divide the actual hours worked by your function point total for that project, and there is your modifier.

This will only give a very crude estimate, but it is probably the best you are going to get. And having a method like this enables you to show your client how you came up with your estimates, at least.

Answer 10

Agile estimation techniques suggest the following techniques:

• Assign a relative size measure to each of your identified "features". Think feature (login), not layer/task (table to hold credentials). T-Shirt sizes work well - S, M, L, XL

• Take a M sized feature, and identify something that the team has already delivered in the desired technology - use this as your expected calibrating measure. So, your team's history shows it can deliver a M feature in 2 weeks. Using S = 1/2M, L=2M, XL=4M, calculate expected project length.

• If your team hasn't already done something comparable; pick a feature and implement it together.

• NEVER quote your calculation as a point in time - always quote it as a range, with a larger range indicating less certainty. (note how MS only predict which year something will be released!)

All that being said, have you considered that you could be asking the wrong question? How much are you willing to risk?

Rather than trying to predict the unpredictable, why not start with as small a team as possible (less communication overhead), and deliver the minimum feature set that gets you into the market place (earlier validation of business/market need).

If that goes well, you'll have a lot more real information on which to estimate future features with a larger team.

Hope that helps!

Answer 11

Firstly let me preface this by saying that no matter what you do your estimate will be wrong. I think you already know this, so with that in mind I'll try to detail what I do when estimate a project:

1. Break the project up into features, where each feature is specific, measurable, achievable and realistic.
2. Give each feature a t-shirt size: extra-small, small, medium, large, xl, xxl.
3. At this point, if you can, negotiate with the customer to reduce the number of XL features to the bare minimum.
4. Create sub tasks breaking down each feature into sub-tasks.
5. T-shirt size each sub-task.
6. Repeat steps 2-5 this time trying to reduce the number of large size features, do this until you have the bare minimum amount required for a version 1.
7. Go through each feature giving each one a time estimate.
8. Sum your estimates.

At this point you'll have the super unrealistic magic best case estimate in man hours/days. I suggest multiplying it by at least two.

You can divide this by the number of available developer resources you have at your disposal to get the number of days to ship.

I highly suggest taking this information and putting it something like (fogbugz)[www.fogbugz.com]. You can then mark your actual time against your estimated time to get a better idea of when your ship date will realistically be.

Software estimates are nothing more than guesses, however with proper tracking you can refine that guess as you get closer to your goal. If you can't measure it you can't manage it.

Good luck with the project, I hope it ships on time!

Answer 12

As others already mentioned break out the task items and estimate each of them. I would add to that to make sure you add some additional common tasks such as:

1. Deployment time (include several; dev, stage, production etc)
2. Unit tests
3. DB modeling
4. Solution setup
5. Domain model pattern

I've found that on any big project these are the most important as they set the foundation to get devs working productively in parallel.

[edit]

I also have found it best to stagger devs in to a new big project. Start with a couple devs (your best ones) to get the the common framework tasks to a point where others can start working in parallel on features and be productive. I've been on projects where they just throw several devs in at once and each does their own thing and the project turns into a hodge-podge of conflicting ideas. Doing it this helps with quality and consistency.

If you've estimated the common tasks decently you can anticipate timing wise when to stagger the next dev in.

Answer 13

Don't spend forever on estimating.

• Try to split everything up into tasks, where the longest is no longer than a week
• no feature takes less than 1/2 a day
• add a random number of unknown tasks for things nobody thought of (the known unknowns)
• add everything up and multiply the result by 3.

Additionally, always remember the Mythical Man Month and/or Code Complete, that the more people on a project, the less efficient any single person is.

Better yet, go Agile.

Answer 14

How many people to hire for a startup?

You are not ready to hire anyone until you have a batch of (pick your vocabulary, user stories, function points, ...)

So maybe you need to start by hiring a project owner to do this level of analysis.

Then, hire two to work as a pair on this list for two weeks, they will be able to tell you the 'width' of the work list. Hire enough pairs to fill the width and hire an architect to work with the original project owner to continue to expand the list.

And, don't start any of this unless you have a direct path to the people how can explain exactly what you have to produce.

Answer 15

There is practically no such thing as a reliable estimate based on coarse requirements. In fact, in my experience, any single task estimated at more than 1 day is a strong indication that the task needs to be broken down further into subtasks.

Even a week-long estimate usually turns out badly. In my experience, most tasks estimated at 1 week without further details end up taking 2-3 weeks, and the problem only gets worse with larger projects.

It's largely psychological. We know that as programmers/designers/architects, we are optimists. When we give ourselves a long, nebulous target to hit, it's incredibly easy to feel like we are ahead of the game even though we really aren't. 4 more weeks? And all I have to do is fix the broken search function that was working last week? That's easy! Let's put it aside and work on some fun Ajax fade effects.

Having said this, there is a particular heuristic I often use for back-of-the-envelope estimates, and let me be crystal clear that these are never actually committed to or used in project plans - they're simply ways to help answer the question that customers and managers always ask, "so let's say we want to do <some_vague_project>, how long do you think that would take?"

First I identify certain facets of the project, namely:

• Expected lifetime - run-once, temporary, or permanent?
• Originality of project - have we done anything like it before?
• Level of domain knowledge required vs. known - do the specs have a learning curve?
• Volatility - how clear is the scope/ownership, how likely is it to change?
• Impact - will it support/replace a critical business function?
• UI complexity - less than 5 screens, less than 20, or more?
• Is it customer-facing? (If so it will need to go through a zillion revisions)
• Does it need to interoperate with any other systems?

Then I usually assign "points" to each of these (note that this is not a "system", this all happens in my head and usually requires fine-tuning). Tally up the points for an approximate project size:

• No points: 1-2 days (a script)
• 1 point: 1-2 weeks
• 2 points: 2-4 weeks
• 3 points: 1-2 months
• 4 points: 3-6 months
• 5 points: 6-12 months
• 6 or more points: No clue.

Note what I'm doing here - there's a more-or-less exponential rate of growth with complexity. When you add a new wrinkle, such as that the app is customer-facing, that doesn't just add a little extra time to the project, it doubles or triples the time because now everything will take longer as a result of having to be vetted for language, legal, look and feel, etc. Same idea if it's replacing a critical business function; now every single component needs to be written defensively to plan for every possible contingency.

I want to repeat for the record that this is of no practical use in a real project plan and I would never actually commit to a project timeline without breaking down the entire spec into tasks of a maximum size of 1-2 days. This is only for answering quick, off-the-cuff questions when customers/managers effectively ask me to do the math in my head and aren't willing to take "I don't know" for an answer.

Once again, just to be absolutely sure everybody heard me: Do not use this method to create an actual project estimate. It is at best useful for coming up with a minimum baseline project "size", something you can say in a board meeting to set some semblance of an expectation without signing on the dotted line.