Sunday, August 3, 2014

Project schedule and estimates

I started reading Joel on Software (the book, made from the website) a few months ago and just picked it up again recently. I left off on a chapter about specs, which I skipped over (which is probably why specs are so underused), and came upon the chapter on scheduling.

I like the simple, pragmatic method for creating a project schedule. Basically in a spreadsheet write down columns Feature | Task | Priority | Orig Est | Cur Est | Elapsed | Remaining

First, each feature needs to be broken down into tasks. Next, estimates should be given in hours. The more precise the unit of measure the more the programmer has to think about how they're going to accomplish a task. This naturally leads to developing a design. Tasks might even need to be broken down even more until they are no longer vague. This will naturally follow from precise estimates because it's easier to give estimates for concrete tasks.

So now we have each feature broken down into concrete tasks with estimates and a well thought out design. Who would've thought precise estimates could result in a well organized project?

In Pragmatic Programmer they said to use higher units of measure when giving estimates because "2 months" is alot more flexible than "50 days". When you say "50 days" they really, really expect you to be close to done in 50 days. Conversely, when you say "2 months" you can be off by a few weeks in either direction and it's fine.

Here's how I'm going to give both precise estimate and higher units of measure.
1) Use the simple spreadsheet method and break down features into tasks, giving very precise estimates in hours.

2) When it comes time to give my estimates to managers I will roll up the estimates from the spreadsheet for each feature and then translate it into a less precise unit of measure.

Let's say I am given a new project with 3 features. The first thing I'm going to do is write these 3 features into the spreadsheet in the format mentioned above. Then I'm going to go through each feature one at a time and figure out the steps needed to complete this feature. While doing that I'm going to write down the estimates. If I can't give a good estimate for one of the tasks then I need to break that task down further. As a boring example:
Feature 1 has 4 tasks for a total of 36 hours
Feature 2 has 10 tasks for a total of 60 hours
Feature 3 has 2 tasks for a total of 8 hours

I wouldn't present those numbers to a manager. First, i would translate it into a less precise unit of measure.
And remember, 1 day = 8 hours. 1 week = 5 days = 40 hours. Don't estimate with overtime taken into consideration, because then you're going to be expected to work overtime!

36 hours is roughly 1 week. 60 hours is 1.5 weeks. And 8 hours is 1 day. Those are the times I would give to a manager. Now the manager has good information for deciding what to tell the customer, and ultimately for deciding which features to keep and which to cut.

So that's how I'm going to use the precise project schedule estimates and also give the less precise estimates to managers.


No comments:

Post a Comment

There was an error in this gadget