3 ms·

Chiming in with helpful rules of thumb I go by: 1. Never give an estimate in the same conversation in which it was requested, unless you're quite sure the answ

Chiming in with helpful rules of thumb I go by: 1. Never give an estimate in the same conversation in which it was requested, unless you're quite sure the answer is "less than an hour". Especially if they are going to turn around and quote your timeframe to a customer. The reason for this rule is: 2. The more you think about an estimate, the higher it will go. "Oh yeah and we'll also have to..." is 100x more common than "I found a shortcut that doesn't compromise on..." 3. Even if they know it's an estimate and not a deadline, they might not know the difference between "40 hours of dedicated effort" and "One week's worth of business hours". Making that distinction is just as important as the estimate/deadline distinction. I'm lucky to work where we don't spend much effort on estimates and time tracking, both of which just make things take longer and cause productivity-reducing stress.

datadrivenangel 2y ago
The distinction between labor time and calendar time is an important one! 40 hours of dedicated effort is great, but most people parse that as "1 week" when in reality the available people may only be able to get 10 or 20 hours in a week due to other demands, or it's 38 hours of dedicated time that gets done in 1 week but the 2 hours of security and legal reviews take a month of waiting to finally get completed.
- ozim 2y ago
  I call it lead time and labor time. 1FTE labor will be x hours but lead time can be couple weeks depending on where are we in development cycle.
  - ryoshu 2y ago
    This is great framing.
wkirby 2y ago
> The more you think about an estimate, the higher it will go This is excellent advice. At Apsis, we have a collection of "red flags" for any project that we call out specifically as likely sources of increased complexity and therefore a higher estimate. Some of these are: * integrations external APIs * existing tech from the client with no provided documentation * any new infrastructure being spun up
yencabulator 2y ago
> 3. Even if they know it's an estimate and not a deadline, they might not know the difference between "40 hours of dedicated effort" and "One week's worth of business hours". Making that distinction is just as important as the estimate/deadline distinction. This is the motivation for "story points", to avoid saying "hour" for the former. (And secondarily, let the ratio of the two be discovered by analyzing previous work, in a stable team setting.)

datadrivenangel 2y ago

The distinction between labor time and calendar time is an important one! 40 hours of dedicated effort is great, but most people parse that as "1 week" when in reality the available people may only be able to get 10 or 20 hours in a week due to other demands, or it's 38 hours of dedicated time that gets done in 1 week but the 2 hours of security and legal reviews take a month of waiting to finally get completed.

ozim 2y ago
I call it lead time and labor time. 1FTE labor will be x hours but lead time can be couple weeks depending on where are we in development cycle.
- ryoshu 2y ago
  This is great framing.

wkirby 2y ago

> The more you think about an estimate, the higher it will go This is excellent advice. At Apsis, we have a collection of "red flags" for any project that we call out specifically as likely sources of increased complexity and therefore a higher estimate. Some of these are: * integrations external APIs * existing tech from the client with no provided documentation * any new infrastructure being spun up

yencabulator 2y ago

> 3. Even if they know it's an estimate and not a deadline, they might not know the difference between "40 hours of dedicated effort" and "One week's worth of business hours". Making that distinction is just as important as the estimate/deadline distinction. This is the motivation for "story points", to avoid saying "hour" for the former. (And secondarily, let the ratio of the two be discovered by analyzing previous work, in a stable team setting.)