Estimating using Work Breakdown Structure

Work Breakdown Structure (WBS) is probably how 98% of software development projects are estimated. WBS consists of someone sitting down and saying "Okay, how are we going to get this done?", then coming up with a long laundry list like this:

1. Setting up Development, Test, and Production environments - 8 hours
2. Creating the Login screen - 4 hours
3. Creating the Landing Page - 2 days
4. Developing the XYZ Page - 12 hours
5. etc., etc., etc.

You then continue with a long laundry list of every task you can imagine, with each task having an associated estimate. At the end you add up the time for all the tasks, and you have your overall time estimate.

Or do you?

WBS accuracy

As a practical matter, most WBS estimates I've seen under-estimate the total time required by a factor of 1.25 to 2.5. That is, if someone tells me that they did a WBS estimate and came up with 100 hours, the real answer is typically 125 to 250 hours.

IFPUG data also supports this. Though I don't have the exact data with me, I do remember that their data shows that estimates created using WBS alone under-estimate project effort by an average of about 50%. The reality is that this ratio actually varies quite a bit from person to person: some developers over-estimate, some under-estimate, some are very close. The good news is that people are consistent, and if they usually under-estimate by a factor of 2.5 they tend to always estimate by a similar ratio, unless ...

Use feedback to improve WBS estimates

If these developers are made to always review their estimates I believe they will eventually get better. For instance, let's say a developer told me a project would take 100 hours, but it really took 250 hours. After the project I would sit down with the developer and say "Okay, you estimated 100 hours, but it really took 250 hours. Now, I'm not here to beat you over the head. In fact, we like you quite a bit and want you on all of our future projects. But we need to take a little time and see where this estimate was off, okay?"

You do this behind closed doors, because everybody I know feels vulnerable when they're estimating. This stuff is hard, and it's not an exact science, I know that. But if you don't go through this process people won't get better.

Getting back to the WBS estimate, let's imagine that we worked through this process and we came up with an estimate of 1,600 hours. Given our team of four developers, this equates to 400 hours per developer. At 35 hours per week this is about 11.4 weeks of development effort.

Don't forget acceptance testing

Historically speaking, the people that I've seen take the WBS effort do not include final acceptance testing in their estimates, so I'll assume that's the case here. I'll use the same ratio of development time to final acceptance testing time that I used before (a 3:1 ratio), so if development takes 11.4 weeks, acceptance testing should take an additional 3.8 weeks (and the 1,600 hour estimate needs to be increased to 2,133 hours).

WBS estimate

Therefore, WBS predicts a total development time of 2,133 hours, or 15.2 weeks.

Up: Cost-Estimating Previous: Estimating using FPA and Next: Estimating using Construx Estimate   Contents