Fog Creek Software
Discussion Board




Fuzzy front and back end estimates

Okay, the company I work for used to have an attitude of "Schedules? We don't need no stinkin' schedules! We'll stick our finger in the air and force our programmers to work overtime if they're late!" Not so hot. So we've taken it upon ourselves to do schedules.

Now, I'm now pretty good at estimating how long it's going to take to do individual tasks, when they're broken down into small half day or day long activities. And I make sure to put a load of buffer time in at the end. Yet I still find I'm struggling to meet deadlines.

What I've discovered is there are two activities that are difficult to estimate.

The first is the amount of time it's going to take to nail down the initial requirements, bang out a spec and some top level design, and come up with a schedule. Call this the "fuzzy front end".

From my experience, this seems to be about a tenth of the time it'll take to do the tasks (not including buffer). Eg: an increment taking 30 man days took 3 days to design and write a schedule for. However, I couldn't have really said at a glance, "oooh that increment's going to take about 3 days to design" - I had to sit down and analyse it.

The second is the number of times the test team are likely to have to run through the whole retest before they can't find any more bugs. This is tricky when doing a whole retest takes several man days. (Hmm, automated testing is your friend?). Call this the "fuzzy back end".

From my experience it's about four or five times. What's worse is that towards the end of the project, corners get cut, so regression testing isn't done as thoroughly as I'd like, and every now and again something gets shipped with a silly bug I accidentally put in to fix a more tricky bug at the last minute.

Thoughts and comments? I'm asking this now really because management are banging on my door for accurate timescales for the rest of the year, and I just haven't done the design to give them something I'm comfortable with.

Better than being unemployed...
Wednesday, January 22, 2003

If you haven't done enough designing yet to give them firm estimates just stick to your guns and tell the managers to hang on.

The managers may get a bit annoyed but just guessing will only get you into more trouble in the future with them anyway.

Matthew Lock
Wednesday, January 22, 2003

From some of the phrases in your post, I'm guessing you have already read Steve McConnells 'Rapid Development' book. If not, then you should. Amazon or somewhere will have it.

I haven't checked, but some excerpts from the book may contain the info you need and are on S McC's website  www.construx.com 

If they're hammering on the door or you can hear frantic whispering outside, then it's probably too late to start shopping for books. Do it later, maybe...

Your real problem is do you let them down now (by telling them they'll have to wait for an estimate/design) or later (when your estimate proves inaccurate)? If you take the second course and you're wrong, not only do you get your arse chewed for failing to deliver, but you reputation suffers too (much harder to repair).

You still have to estimate the estimation time and they'll be chasing you while waiting for that.

Justin
Wednesday, January 22, 2003

The best book on project management I've read so far is DeMarco's "The Deadline". Tons of DOs and DONTs in this book and once you try them out you'll realize they're actually quite true and real!

It is now my experience that in large projects design, coding and testing have equal durations. Requirements would take longer than any of the above.

In the above I'm assuming a use case driven development process and automated testing.

Also, estimates are indeed correct only for half a day to a day's worth of working. This assumes the existence of a complete task list which of course depends on the overall system design.  Same way, projects longer than a year (maybe a bit more) cannot be managed and should be broken into smaller subprojects/iterations/phases.

Hence, in large projects one must first nail down the requirements, then come up with a rough model and only after this come up with a project plan. As a first step I would plan only the requirements phase using about a third of the available time.

For really small projects (like 30-100 man days) I would push for a demo every 2-3 days. Usually specs for such projects are vague and utterly uselss beyond offering a starting point. I put more value on the demo feedback which will keep the project on track and target.

As far as last minute changes, I'd rather release a product with known problems than throwing in quick fixes. I found out (the hard way) that quick fixes are the usually creating more problems than solving.

Dino
Wednesday, January 22, 2003

Excellent topic, Better.  Thank you.

One solution:  Refuse to include design and testing time in your estimates.  Refer to design and testing as separate activities that cannot be estimated.  Your customer may balk, but this is the truth.

You wrote that design takes "about ten percent of the time."  Use that as your default estimate.

You can eliminate the "fuzzy back end" using test-first implementation.  Write tests for your production code BEFORE you write the production code.  Then run the tests (as a sanity check).  Then write the production code, and run the tests again.  As a result, QA should find very few bugs.  (And pass around these tests, so that Jane can use them when she's assigned to update the features you've worked on.)

Brent P. Newhall
Wednesday, January 22, 2003

"Refuse to include design and testing time in your estimates..."

This may just be the tragedy of my past experiences speaking, but I've found it's very important (for my manager and/or customer, but usually the former) to specifically break-out testing in an estimate.  Some managers think testing is "easy" and/or the "test as you're developing" method is sufficient.

As such, I've found that a line item like TESTING = X [hours/days] is a requirement to helping management understand that it takes time to test (particularly if you have non-technical management).  Otherwise, it's really easy, I've found, for management to "forget" about the testing phase.

But then again, I've spent most of my time working as a solo developer while reporting to Director/VP-types, so others' experiences may differ.

Jeff MacDonald
Wednesday, January 22, 2003

Always make sure that grey areas are specified, if there are dependancies that cannot be estimated make sure they are in black and white, why put your head into a noose created by somebody else?

my 02c.

Alberto
Thursday, January 23, 2003

I can't see management here buying "grey areas", but it's not a bad idea, providing a date with a "plus or minus" factor. I'll try that.

Only trouble I can see is they'll take the two extremes as absolute values and pick one of those.

In another thread, I was reading about how people who don't have as strict a schedule produce stuff more quickly. Interesting, because I would have assumed the opposite. I guess it depends on the quality of your team.

I'm getting pissed off here that QA don't try and test stuff until after I've finished all my implementation, unit testing and integrating. Probably because, between you me and the gatepost, our test team is a bunch of idiots who can't grasp the concept of testing a build with 50% of the proposed functionality in.

That just slows everything down because testing doesn't get done in parallel, which means the fuzzy back end can't be estimated until the end of development. Not so good.

Better than being unemployed...
Thursday, January 23, 2003

If management has a tendency to pick one of two extremes, only give them the extreme that specifies the most testing time.  This is better for them and better for you.

Brent P. Newhall
Thursday, January 23, 2003

>Probably because, between you me
>and the gatepost, our test team is
>a bunch of idiots who can't grasp
>the concept of testing a build with
>50% of the proposed functionality in.

Teach them about modularity and incremental
delivery.  Do a lunch & learn.  This is low hanging fruit! :-)

Matt H.
Friday, January 24, 2003

*  Recent Topics

*  Fog Creek Home