3 ms·

This is why it’s a good idea to have ranged estimates. If a simple known thing with zero unknowns has maybe a 200% margin (1-3 days) then a more unknown task ca

This is why it’s a good idea to have ranged estimates. If a simple known thing with zero unknowns has maybe a 200% margin (1-3 days) then a more unknown task can have 10x as wide margin like 1 to 20 days. As a developer I never get “that’s a useless estimate we can’t prioritize based on that/tell the customer that”. It’s a perfectly good estimate. It tells everyone there is a lot of uncertainty. The low lower bound indicates there is a chance it might turn out to be cheap (so maybe worth taking a gamble and trying it and giving up). The big variance indicates it could/should be given some time to prep/investigate in order to narrow the estimate. When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead.

kelnos 4y ago
The SO question addresses this, though: after giving an estimate with a range, the developer is pressured to narrow that range, mainly by pulling in the farther-out date in the range, and then the developer is blamed when the project inevitably comes in late because of that. Maybe the solution here is "stick to your guns", but that can have negative career implications.
- alkonaut 4y ago
  That’s perfectly expected. But the key is: narrowing the estimate isn’t free. You can’t pull a different estimate out of thin air. And zero people will expect it. The developer needs to say “I can say 10-100 days right now in this meeting, but given just 1 day of investigating, I’ll narrow the estimate range by an order of magnitude”.
  - deleted 4y ago
    [deleted]
InexSquirrel 4y ago
I agree with this sentiment. I'm running through a similar situation now, where I'm somewhat adjacent to a client and a dev team. The client has a list of tasks he wants done, and he'd like banded estimates for the effort the dev team thinks it will take to complete each. The developers are obliging, but one of them complained to me privately "why doesn't he just give us 2 months of budget and we'll get through as much as we can?" - which is an interesting statement. From the developer's perspective, this is ideal. They are very good and work hard and have integrity, so I'm sure something like that would work, from their perspective. They can just 'go' and get stuff done. From the client's perspective though, it just raises a bunch of uncertainty. He wants to know what he could get out of his 2 months of development budget. If one task took all 2 months, and the others (15 in this case) didn't get done, is that OK? What if some important task wasn't that much effort? You'd potentially want to priortise that over a bigger item. Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships.
- ryanbrunner 4y ago
  > Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships. The irony is that at least some of the time, a "safe" estimate will actually make the project take longer. Work naturally expands to fill a deadline, and not having a deadline but instead frequent progress checkins with an expectation of foward progress can result in more getting done, because it changes the conversation from "how at risk is the deadline" to "how much happened in the last week and what are the next steps", forcing progress to happen continuously rather than one big bang at the end. I also often hesitate to give estimates / establish deadlines because it tends to create an unhealthy confrontational atmoshepere, where developers are incentivized to not incorporate feedback or make any changes even if they are the right thing to do, because it would put the deadline at risk (but if they incorprate allowances for these things during estimation it's considered sandbagging).
AlotOfReading 4y ago
I'm fairly certain that you aren't accounting for uncertainty properly, especially with long-tail events. Let's say you have a ticket to enable a config flag. That's low risk and relatively small. There's still a risk that there's the flag hits a silicon bug. Does your estimate reflect that risk and is it useful if 95% of tasks don't hit those issues? Consider also that estimates delivered by contractors or even other teammates will not reflect these risks and thus you look correspondingly pessimistic or even lazy. For context, my team is in exactly this situation with several silicon bugs we found last month.
- dclusin 4y ago
  Assuming you’re pretty close to the hardware? As a standard backend web service dev os/library/device bugs are incredibly unlikely and usually defective application software is to blame. Not saying it doesn’t happen, but I can’t recall in recent memory this sort of thing happening as high up in the stack I work.
  - AlotOfReading 4y ago
    That's just the sort of stuff I see, but long tail issues that take weeks or months to diagnose can happen anywhere in the stack. Sometimes it's a hardware issue, sometimes it's a compiler bug, sometimes a VM bug, a missing browser feature, etc. Any of that can crop up even with "trivial" changes. I'd argue that it's not useful to include that in your estimates, but they're nevertheless possible and need to be incorporated in scheduling.
- antipotoad 4y ago
  May I ask how you identified them as silicon bugs? And by silicon bugs do you mean random bit flips, or something else?
  - AlotOfReading 4y ago
    I probably should have said hardware bugs, as only one is in an IC (specifically an IP block). It manifests as small (but out of spec) timing errors across a network. The rest are things like improper layout, faulty components, wrong value passives, etc.
idopmstuff 4y ago
> When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead. As a PM, I couldn't possibly agree more with this. When you give me 5-200 days instead of "we can't estimate this", you've started the beginning of a productive conversation. I can ask you questions about why the range is so big, and you can explain to me what steps we can take (research, narrowing scope, etc.), to reduce the range.
- jiggawatts 4y ago
  I’ve tried this. Inevitably the response is: “We need to book UAT testers for a specific date.” Ordinary LoB staff apparently are superstars that have their schedules locked in months into the future, but consultant SREs costing thousands a day can have their time wasted on a daily basis trying to determine how long it will take to complete a task that hasn’t even started yet. This has literally been my last two months. The dev team lead is asking me — an outsider — how long it’ll take his team to finish something. Not because I know better, but because he doesn’t know either and prefers to make it my fault because I’m expendable.
  - roenxi 4y ago
    Well, analysing the situation that seems like quite an easy one to negotiate through: 1. Talk to the person who'll get angry at you when the UAT testers are brought in at the wrong time. 2. Make it clear to them, with a paper trail, that this is an impossible task and you can either book in a best-estimate with the likely outcome that the UAT testers will arrive and there will be nothing to test OR that you can book conservatively and there is a risk the project will be delayed waiting for UAT. They can pick which risk they want to bear. 3. Put in formal feedback, as loudly as possible, that booking in UAT for a specific time introduces obvious risks and someone needs to optimise the process to be more flexible otherwise it will delay projects & waste the businesses' money.
  - 8note 4y ago
    An interesting swap would be to get them to give an estimate for when they'd be ready for UAT, and then you take on booking the UAT. If you're the user or representing the user, shouldn't you be doing the UAT?
julian_t 4y ago
Yes - it's better to be accurate than precise. If you said "1 to 20 days" and it took 15, you were accurate. Being too precise gives you no space for the unknowns to show themselves.

kelnos 4y ago

The SO question addresses this, though: after giving an estimate with a range, the developer is pressured to narrow that range, mainly by pulling in the farther-out date in the range, and then the developer is blamed when the project inevitably comes in late because of that. Maybe the solution here is "stick to your guns", but that can have negative career implications.

alkonaut 4y ago
That’s perfectly expected. But the key is: narrowing the estimate isn’t free. You can’t pull a different estimate out of thin air. And zero people will expect it. The developer needs to say “I can say 10-100 days right now in this meeting, but given just 1 day of investigating, I’ll narrow the estimate range by an order of magnitude”.
- deleted 4y ago
  [deleted]

InexSquirrel 4y ago

I agree with this sentiment. I'm running through a similar situation now, where I'm somewhat adjacent to a client and a dev team. The client has a list of tasks he wants done, and he'd like banded estimates for the effort the dev team thinks it will take to complete each. The developers are obliging, but one of them complained to me privately "why doesn't he just give us 2 months of budget and we'll get through as much as we can?" - which is an interesting statement. From the developer's perspective, this is ideal. They are very good and work hard and have integrity, so I'm sure something like that would work, from their perspective. They can just 'go' and get stuff done. From the client's perspective though, it just raises a bunch of uncertainty. He wants to know what he could get out of his 2 months of development budget. If one task took all 2 months, and the others (15 in this case) didn't get done, is that OK? What if some important task wasn't that much effort? You'd potentially want to priortise that over a bigger item. Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships.

ryanbrunner 4y ago
> Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships. The irony is that at least some of the time, a "safe" estimate will actually make the project take longer. Work naturally expands to fill a deadline, and not having a deadline but instead frequent progress checkins with an expectation of foward progress can result in more getting done, because it changes the conversation from "how at risk is the deadline" to "how much happened in the last week and what are the next steps", forcing progress to happen continuously rather than one big bang at the end. I also often hesitate to give estimates / establish deadlines because it tends to create an unhealthy confrontational atmoshepere, where developers are incentivized to not incorporate feedback or make any changes even if they are the right thing to do, because it would put the deadline at risk (but if they incorprate allowances for these things during estimation it's considered sandbagging).

AlotOfReading 4y ago

I'm fairly certain that you aren't accounting for uncertainty properly, especially with long-tail events. Let's say you have a ticket to enable a config flag. That's low risk and relatively small. There's still a risk that there's the flag hits a silicon bug. Does your estimate reflect that risk and is it useful if 95% of tasks don't hit those issues? Consider also that estimates delivered by contractors or even other teammates will not reflect these risks and thus you look correspondingly pessimistic or even lazy. For context, my team is in exactly this situation with several silicon bugs we found last month.

dclusin 4y ago
Assuming you’re pretty close to the hardware? As a standard backend web service dev os/library/device bugs are incredibly unlikely and usually defective application software is to blame. Not saying it doesn’t happen, but I can’t recall in recent memory this sort of thing happening as high up in the stack I work.
- AlotOfReading 4y ago
  That's just the sort of stuff I see, but long tail issues that take weeks or months to diagnose can happen anywhere in the stack. Sometimes it's a hardware issue, sometimes it's a compiler bug, sometimes a VM bug, a missing browser feature, etc. Any of that can crop up even with "trivial" changes. I'd argue that it's not useful to include that in your estimates, but they're nevertheless possible and need to be incorporated in scheduling.
antipotoad 4y ago
May I ask how you identified them as silicon bugs? And by silicon bugs do you mean random bit flips, or something else?
- AlotOfReading 4y ago
  I probably should have said hardware bugs, as only one is in an IC (specifically an IP block). It manifests as small (but out of spec) timing errors across a network. The rest are things like improper layout, faulty components, wrong value passives, etc.

idopmstuff 4y ago

> When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead. As a PM, I couldn't possibly agree more with this. When you give me 5-200 days instead of "we can't estimate this", you've started the beginning of a productive conversation. I can ask you questions about why the range is so big, and you can explain to me what steps we can take (research, narrowing scope, etc.), to reduce the range.

jiggawatts 4y ago
I’ve tried this. Inevitably the response is: “We need to book UAT testers for a specific date.” Ordinary LoB staff apparently are superstars that have their schedules locked in months into the future, but consultant SREs costing thousands a day can have their time wasted on a daily basis trying to determine how long it will take to complete a task that hasn’t even started yet. This has literally been my last two months. The dev team lead is asking me — an outsider — how long it’ll take his team to finish something. Not because I know better, but because he doesn’t know either and prefers to make it my fault because I’m expendable.
- roenxi 4y ago
  Well, analysing the situation that seems like quite an easy one to negotiate through: 1. Talk to the person who'll get angry at you when the UAT testers are brought in at the wrong time. 2. Make it clear to them, with a paper trail, that this is an impossible task and you can either book in a best-estimate with the likely outcome that the UAT testers will arrive and there will be nothing to test OR that you can book conservatively and there is a risk the project will be delayed waiting for UAT. They can pick which risk they want to bear. 3. Put in formal feedback, as loudly as possible, that booking in UAT for a specific time introduces obvious risks and someone needs to optimise the process to be more flexible otherwise it will delay projects & waste the businesses' money.
- 8note 4y ago
  An interesting swap would be to get them to give an estimate for when they'd be ready for UAT, and then you take on booking the UAT. If you're the user or representing the user, shouldn't you be doing the UAT?

julian_t 4y ago

Yes - it's better to be accurate than precise. If you said "1 to 20 days" and it took 15, you were accurate. Being too precise gives you no space for the unknowns to show themselves.