There are alternative techniques to do this, but of the ones I've tried the one I'm going to describe results in the most accurate development time estimates. It should be noted that I didn't come up with this technique myself, it was shown to me by more senior developers at the software firm I currently work at - and seeing as it's used throughout this international company it should be reliable.
An Overview of the WBS Technique.
- The optimistic (best case) time.
- The pessimistic (worst case) time.
- The realistic (most likely) time.
You would place each of these values along with a description of the task into this WBS template. The template will calculate a PERT (also called the expected time) for every task, and sum them up. The resulting four values can be used to better plan the time requirements of your development efforts.
Preference for estimate accuracy is usually given to the PERT - but the other values can be useful if you need to include contingency/buffer times in your calculations.
How Much Detail to Include?
- Design back-end structure
- Design UI
- Implement back-end
- Implement UI
The answer to this question will vary by project, my rule of thumb is to break up your top-level tasks into at least 3 subtasks. If you find it hard to estimate time for a task with any degree of certainty, then break that one up further. For example you might break up testing into:
- Create test cases
- Implement automatable test cases
- Perform manual tests
Update, Review, and Reflect - it's important.
- Is there any may to decrease the remaining times?
- Do I get in external help?
- Should I scrap the project?
- Should I cut out certain program features?
- Is it worth sacrificing quality?
- Can I (or should I) cut corners?
Extra Feature WBS.
If you have any suggestions for some kind of extra-extra features, leave a comment and I'll try and include them in an updated version.