Question

The scale of an open source project is completely different from the projects I do at the office. Work is done in spare time, volunteer work that may not materialize, personal development resources, not corporate, etc.

Clearly the chestnut “do the smallest thing that works” applies, but beyond that, are there any more formal methods to estimating the appropriate size for an open source project, for example, number of tables, number of web pages, or–heaven forbid–function points counting?

What estimation tools would work best for these sorts of projects?

Answer 1

I was recently asked to estimate how long it would take to build an enormous system just by looking at screen shot mockups. Mgmt was asking for a gut feel in under an hour without asking any questions.

I listed out all the modules (pages, reports, big queries, etc.) that I could see and started giving them relative estimates. e.g.:

1. Task 1: 8 units
2. Task 2: 16 units
3. Task 3: 4 units

Then I added a bunch of modules we had already done for this customer along with the relative number of units and actual number of hours/days. This told me what my ratio of units to hours was so I could guess (more than estimate) how long the unknown tasks should take. For example, if I found that an 8 unit task took us 16 hours in the past (2 hours/unit), I’d estimate that the above tasks might take:

1. Task 1: 8 units * 2 hours/unit = 16 hours
2. Task 2: 16 units * 2 hours/unit = 32 hours
3. Task 3: 4 units * 2 hours/unit = 8 hours

This approach enabled me to methodically consider the work to be done and apply some structure around guessing how long it would take to implement.

Of course I delivered my +/- guess with a generous disclaimer.

---

Then, if you want a calendar schedule from this, estimate how many hours per week you will work on the project and see what you come up with.