Estimating project completion time...

[stoymigo]

I've been working at a company for just over 3 months now, adding new features/fixing bugs and starting new projects(small ones), since I'm still new I don't give estimates because I seem to be getting the work done.

How does one start preparing for this, my work is somewhat repetitive, so if I get work to do that I've done before then I can estimate roughly within an hour per feature, but not when I'm given something new that I'm not sure how to do.

Does it come with experience, should I use some tools, or should I be patient because I'm still new?

Thanks

 

[crackersa]

does your company use waterfall, sdlc or agile (or some other form of project management).

you should start of by laying out the framework of your product on paper seeing how the whole process flows in an out (design session), this helps identify all your features and if there's any dependencies on each other.

if you take waterfall or sdlc, you should be creating a work breakdown structure (wbs) which will list all your tasks that are required to develop the product. you would start by listing all the features, and under each feature listing all the work (tasks) required to complete the feature (don't' forget code review and code merges).

once all the tasks are listed, then you are going to assign length of time to each one. a task shouldn't be shorter than a half day and no longer than 2 days (but this isn't written in stone).

To help figure out how to determine how long a task is going to be you have several options available right in your office. there's referring to previous similar projects (this is extremely helpful especially you worked on those projects), co-workers (specifically senior devs) as well as using PERT (calculation that considers best case, worst case and most likely and averages it out and applying a weight to it).

over time you will get better and better at it but you should never stop using these methonds cause that one project that you fail on is the one you will always be remembered for.

i only started to get into Project Management here, so you might want to scour the web for further info. there's tons of sites out there!

 

[crackersa]

oh and one key thing that most forget, there's no way you can commit yourself to 8 hours of code a day (without working overtime) due to meetings and general interruptions. so put your self at 80% which is about 6.4 hours a day.

 

[zippy]

I've been working at a company for just over 3 months now, adding new features/fixing bugs and starting new projects(small ones), since I'm still new I don't give estimates because I seem to be getting the work done.

How does one start preparing for this, my work is somewhat repetitive, so if I get work to do that I've done before then I can estimate roughly within an hour per feature, but not when I'm given something new that I'm not sure how to do.

Does it come with experience, should I use some tools, or should I be patient because I'm still new?

Thanks

It comes with experience. Estimating for completely new system and estimating for adding bits to an existing system is very different. Small projects that add functionality to an existing system should have estimated done by someone who knows that system very well.

The single best tool in the industry is the human brain. If you lack experience then the chances of screwing up because some software planning tool gave you the wrong answer is great. Garbage in - Garbage out