Steps for A Sane Development Estimate
"Send me your dev estimate."
This directive is made by project managers probably 30 times a week. I've found that shooting off a quick email like "ten days" is asking for trouble.
The problem is that PM's are interested in dates, and little else. They want your estimate so they can plan the project, so they can tell their boss when to expect the launch.
They don't care about the breakdown of your tasks, or how much time each contributed. They just want to get that big red X put on the calendar.
So, if your dev estimate is "ten days", the PM will happily count 10 business days off the calendar, draw the big red X, and make that the dev complete day. They probably won't ask if you factored in your availability, code review time, or your time for supporting the testing team. They're just happy to get a number.
Of course, things get ugly when it's ten days later, and you're not dev complete because you had two other projects to work on, and you had to wait on the DBA's to dial up the new schema you needed.
To avoid these nasty under-communications, I follow a sort of template for estimating. Here are the main points I always try to cover, followed by a sample estimate email message I might send to a PM.
This directive is made by project managers probably 30 times a week. I've found that shooting off a quick email like "ten days" is asking for trouble.
The problem is that PM's are interested in dates, and little else. They want your estimate so they can plan the project, so they can tell their boss when to expect the launch.
They don't care about the breakdown of your tasks, or how much time each contributed. They just want to get that big red X put on the calendar.
So, if your dev estimate is "ten days", the PM will happily count 10 business days off the calendar, draw the big red X, and make that the dev complete day. They probably won't ask if you factored in your availability, code review time, or your time for supporting the testing team. They're just happy to get a number.
Of course, things get ugly when it's ten days later, and you're not dev complete because you had two other projects to work on, and you had to wait on the DBA's to dial up the new schema you needed.
To avoid these nasty under-communications, I follow a sort of template for estimating. Here are the main points I always try to cover, followed by a sample estimate email message I might send to a PM.
Get a raw person-day estimate.
I list the main tasks and assign them a difficulty. Then I assign a time estimate to each, generally using days as the finest time interval.
As I assign the time, I imagine it's only me doing the work, it's my only project, and I can spend eight solid hours a day on the task with zero distractions.
Far from realistic, but it gets me a best-case number to work from. I call it the "raw person-day estimate".
Put the raw person-day estimate in the subject of your email
Hang on. I just said the raw person-day number wasn't realistic. So why is it going into the subject line of the mail? Don't worry, we'll address it soon enough. For now, the point is to get the estimate in the PM's brain.
Put the raw person-day estimate in the first line of the message.
A little repetitive, but again, you want the point to get across first. I also like to use bold type to emphasize the numbers.
Detail your expected availability
This is huge. This is also the part where we address the unrealistic raw person-day number.
Even if you have only one project, you're not going to spend every minute on it. There are meetings, fire drills, and other projects to work on. I'd be impressed if anyone could spend more than 75% of their time on a single project. So let the PM know the estimate assumes a perfect world of 100% availability, and what you think your actual availability will be in the next few weeks.
By giving the raw and ideal number, you empower the PM to do person-math. A PM might want to put two people on the project instead of one. If your estimate doesn't make any assumptions about the developers' availability, they can slice and dice your number across people without invalidating the estimate.
The raw number (and your corresponding explanation) is also a good reminder to the PM that your time is finite. If they want to put you on a second project, thats fine, but they should expect both projects to take twice as long.
What the estimate includes
Just the high points. PM's don't need a task-by-task breakdown.
What the estimate excludes
These are things that will be outside your control, and that you can't reasonably estimate.
Critical Dependencies
Let the PM know if there are critical path tasks that might blow your estimate away. Usually this happens when some other team needs to do something before you can finish.
Blackout Days
Remind the PM of your upcoming vacation, including holidays that everyone has off. I've done very carefully thought-out estimates of large projects, but neglected to mention that I had a week of vacation planned smack in the middle of the testing cycle.
Here's an example email based on all this:
I list the main tasks and assign them a difficulty. Then I assign a time estimate to each, generally using days as the finest time interval.
As I assign the time, I imagine it's only me doing the work, it's my only project, and I can spend eight solid hours a day on the task with zero distractions.
Far from realistic, but it gets me a best-case number to work from. I call it the "raw person-day estimate".
Put the raw person-day estimate in the subject of your email
Hang on. I just said the raw person-day number wasn't realistic. So why is it going into the subject line of the mail? Don't worry, we'll address it soon enough. For now, the point is to get the estimate in the PM's brain.
Put the raw person-day estimate in the first line of the message.
A little repetitive, but again, you want the point to get across first. I also like to use bold type to emphasize the numbers.
Detail your expected availability
This is huge. This is also the part where we address the unrealistic raw person-day number.
Even if you have only one project, you're not going to spend every minute on it. There are meetings, fire drills, and other projects to work on. I'd be impressed if anyone could spend more than 75% of their time on a single project. So let the PM know the estimate assumes a perfect world of 100% availability, and what you think your actual availability will be in the next few weeks.
By giving the raw and ideal number, you empower the PM to do person-math. A PM might want to put two people on the project instead of one. If your estimate doesn't make any assumptions about the developers' availability, they can slice and dice your number across people without invalidating the estimate.
The raw number (and your corresponding explanation) is also a good reminder to the PM that your time is finite. If they want to put you on a second project, thats fine, but they should expect both projects to take twice as long.
What the estimate includes
Just the high points. PM's don't need a task-by-task breakdown.
What the estimate excludes
These are things that will be outside your control, and that you can't reasonably estimate.
Critical Dependencies
Let the PM know if there are critical path tasks that might blow your estimate away. Usually this happens when some other team needs to do something before you can finish.
Blackout Days
Remind the PM of your upcoming vacation, including holidays that everyone has off. I've done very carefully thought-out estimates of large projects, but neglected to mention that I had a week of vacation planned smack in the middle of the testing cycle.
Here's an example email based on all this:
Hi Trevor,
My estimate for the development work on the shopping cart project is 10 person-days. This assumes 100% of the developer time is spent on the project (mine will likely be about 75% while we deploy the new billing pages)
This Estimate Includes
- Development - Unit Testing
- Code Review
- Deployment to the QA environment
It Does Not Include
- Supporting QA testing
- Deployment to Production
- User Interface Design
Dependencies
- Coding can't begin until the Database team finalizes and deploys the new schema.
Upcoming Time Off
- May 26 for Memorial Day
- June 2-6 for Vacation
1 Comments
Nice Site!
http://google.com