Project Estimates
June 24, 2010 3 Comments
In my previous post on High Level Project Estimates, I talked about 3 points estimates to help provide an up-front estime of effort for a project. Aside from the effort estimate you also need to consider other aspects that the team will spend time on. The following are some aspects I consider with the kind of percentages (above the effort estimate) I have experienced. Note: these percentages are by no means standard or the norm they are essentially a rough guess based on the projects I have worked .
- Planning Meetings @ 10%
- Demos @ 2%
- Code Reviews @ 5%
- Retrospectives @ 5%
- Dark Mater @15%
- Bugs @15%
- New Technical Stories and Spikes @ 25%
- Change Requests (shouldn’t average more than 15%)
- Holidays and Sick Leave @ 5%
You will also need to consider Management Overheads as well as Business Analysts (if included in the team), QA/Functional Testing, Support and Maintenance (if required).
Hi Mash,
Once the requirements estimation is done, how do you add what you described here to the final project estimation?
The items and percentages in this post are very reasonable to me and I tend to agree with the percentage share. Summing them up, we will get to 97%.
How does this percentage relates to the requirement estimation? Would I be right to assume that, let’s say, if requirements estimations gave us 500 units (whatever unit was used: hours, man/day, engineering hours, etc), adding the items you described, the total project estimation would be ~1000 units?
Thanks for your posts on project estimation.
Hi Sandro,
That’s a very interesting question. I don’t think it’s a matter of summing up the percentages to add to initial effort estimate. The way I apply these is incremental in the following order so the end estimate hike would actually be than the 97%.
original estimate + tech stories and spikes
change requests
bugs
dark matter
planning meetings + demos + retrospectives
QA / Testing
Management Overheads
Holidays and Sick Leave
Support and Maintenance should not be applied as a percentage as you would probably fix resources for a specified amount of time so you can easily get a concrete figure and add to the total estimate.
hi Mash,
good estimates. Numbers can vary but I came to the same conclusion that 50% of team capacity go to support smooth scrum delivery.