Poll: What measure do you use to size software?

Question

Intended to be a quick heartbeat of what people out there are actually using to determine software size (which may lead to an estimate) in order to plan and project schedules. Post Unique answers and Vote +1 to second an existing option.

Context : Let me get this off my chest... I detest function points because

• its difficult to count
• there is never enough time
• nothing is clear upfront to get a good count anyway. I'd prefer story points or ideal days or anyUnit instead (Agile Fan-atic @ Heart)

A higher up handed me a (HEAVY) copy of Caper Jones' Applied SW measurements to read... which has been sidelined by my purchase of Peopleware (Double Thumbs up!). Looking from a mgmt perspective, there is a need to predict cost/effort somehow... Just saying that its difficult to measure or "immeasurable" doesn't cut it above a certain level.

Ron Jeffries's idea of RTF (Running Tested Features) is a good metric .. but is hard to sell around here as the Org is slowly (but surely) moving towards agile.

edit: I'm looking at a measure where you can say 'This project is X Units while this is Y Units so it makes sense to do Proj#1 instead of #2 based on relative revenue-cost ratio' - a 'project approval board' level not the developer task breakdown level. Sorry if I wasn't clear at first

End of First Q. ever. SO rocks.

Answer 1

Expert Guesstimate. Before you shrug it off, it works. A lot of times, we break down the project into small tasks, and ask our developers to estimate what it would take for them to finish those tasks.

Sum them up, and add any adjustments based on historical data. And we have an estimate.

We do this when we don't have the liberty of applying more formal methods.

Answer 2

Glance through the first-cut requirements statement and figure out - honestly - how long you think it would take. Don't go crazy - you shouldn't need more note-taking capacity than the back of an envelope.

Now take that estimate, double it and up-tick the unit. So 2 weeks goes to 4 months.

It sounds flippant but it's uncannily accurate, by the time you look back and see how long the damn thing actually took.

Failing that, break everything down to the point where each part can be estimated. I like to put a "fear factor" (low/med/hi) on each and add a lot more contingency where there are major concerns over the perceived accuracy of the estimate. Sum the estimates, then double them and up-tick the unit.

Keep a record of your estimates and actuals. That way you can apply Monte Carlo techniques to turn your estimates into actuals with confidence levels (see how FogBugz does it).

There's a Phil Haack post that's a good starting point for more information.

Answer 3

Function points, sorry.

Answer 4

We use story points, which are estimated by the team before the code is written.

Answer 5

Sort of an extension to the Expert Guesstimate idea: Evidence Based Scheduling.

Answer 6

I don't think it matters what you measure to get your estimate. The reality is you can only estimate on things that you know and are comfortable with. If you want accurate estimates you need to have a track record with doing the same kind of project that you are estimating. If you don't have experience or there are a lot of unknowns then you need to be willing to have a research project to get you to the point of having the information you need.

Your estimate has to be based on a list of known tasks that are needed to achieve the final product. If you don't have that list you can't come up with an estimate. To try to base your estimate on one metric, to me is a guaranteed failure.

I've never used it but I think FogBugz Evidence Based Scheduling looks like one of the best methods around. The first time I read about it I remember thinking that these guys really know what they are talking about.

Fortunately I don't have to produce many schedules. I do support the project management system where I work and I get to see a lot of schedules. Some are pretty good and some are fiction from word one.

Answer 7

> I'm looking at a measure where you can say 'This project is X Units while this is Y Units so it makes sense to do Proj#1 instead of #2 based on relative revenue-cost ratio' - a 'project approval board' level not the developer task breakdown level. Sorry if I wasn't clear at first

You face a couple of minor problems:

1. You can't ever say "it is X units." until you've actually finished.
   At best you can say "it looks like it might be X units."

2. What's a unit?

   • You can't know how many LOC it will be until it's done, and LOC is meaningless anyway
   • Ditto for 'function points'
   • You might consider 'features' as a 'unit', but one feature might look similar to another, but in fact takes 15 times as much work.
   • Ditto for just about any other measurement you might care to think of

IMHO the only actual useful measure you can come up with is developer tasks, and the only way you can quantify developer tasks is by breaking them down into small enough pieces that they can be accurately estimated as taking X hours by the developers who will implement them

---

To answer the original 'poll' question -

All things going well, a feature is proposed, the boss says "How long do you reckon that will take," and I say "I'll work it out and get back to you". I then go and break it down into tasks (just using excel or something), add them all up, and report back.

• Note - I usually do 3 estimates per task - Optimistic, 'Normal', and Pessimistic.

Example: Add button to frobnicator: 3/4/48 hours

• Note 2: I have no idea what happens to these estimates or if they are ever actually anywhere near reality. We need to start doing some postmortems IMHO.