3 ms·

The elephant in the room here is, of course, that often accurate estimates are unwanted. If you tell the truth about how long something will take, maybe your cu

The elephant in the room here is, of course, that often accurate estimates are unwanted. If you tell the truth about how long something will take, maybe your customer will go with someone else. Maybe the CTO will decide to outsource instead of giving the work to your team. You know those other guys are probably as good at estimation as you are, they're just deliberately going low so you have to too. (And thus, everybody now expects IT projects to overrun!) Other than that I agree with most of the linked article, I get very good results by breaking tasks down into smaller (<1 week) jobs and getting a best and worse case estimate for each. Sum both columns, multiply both by some number for unknown unknowns (usually 1.5, 2 when there are bad vibes) and you have a realistic minimum time and a worst case. If the max is >2X the min (it will be to begin with!), get more information to narrow the range, repeat until it's not outrageous.

cratermoon 3y ago
> accurate estimates are unwanted In my career I've learned that estimating usually boils down to a game involving guessing what the customer will accept, while the customer tries to figure out what they want. Dig deep enough, and there's usually a dependency like "it needs to be done before X", but when X will be done is also imperfectly known, so it's a tangle of dependencies. The cases of hard dates usually involve businesses dependent on seasonal, holiday revenue or scheduled events like sports or entertainment touring schedules. Estimating for those is much easier, because the game becomes one of figuring what can be delivered by the date(s) in question. Regulatory changes or fiscal timelines are usually not as fixed as they are believed, because there's lots of ways to paper a path over delays, although its costs money and business don't like that.
dasil003 3y ago
“Telling the truth” implies two things: that the actual effort needed is fixed, and that you know it. In practice I’ve found neither of those things to be anywhere close to true for large projects. Furthermore the pursuit of accuracy by doing finer and finer-grained estimates and then rolling them up can waste a lot of time because it provides fodder for bike shedding while missing the forest for the trees. I can’t count the number of times I’ve seen this process lead to a total train wreck. What works better is to be very clear on the big picture goals, do a speculative high level breakdown to inform an initial deadline and staffing commitment, but keep the precise scope flexible. Then get right into prototyping and building, attacking the areas of largest risk and refining the requirements as you go. You only should have fine-grained plans for the next 2-3 months with the rest of the roadmap intentionally being flexible, save for any key milestones that are needed to ensure progress to the high level goal. Of course this requires deep expertise with cross-functional influence and bi-directional trust with management, but if you don’t have those things big projects are fucked regardless. In that case your best bet is hunkering down with some agile methodology as a shield while looking for a better job.
- digging 3y ago
  I find my biggest hurdle with estimation is often one small requirement which turns out to require a large amount of work. Like, "have this element behave in [unique way] on this page." Ok, well, that element was never even built to be touched individually, let alone have custom behavior. So now it's actually doubled the development time. This is something which can usually be caught during estimation, but occasionally it isn't something you're going to notice until you're actually digging into the code and implementing it. And if you're going that deep during estimation, you're already practically building the thing, so estimation is now taking up a significant amount of time and effort. I am not a super experienced dev, but I haven't really seen a way around these issues cropping up often enough to make estimation feel close to worthless. (that is, it's unreliable often enough that it's unwise to couple any timeline too closely to any estimate)
- brigandish 3y ago
  > What works better is to be very clear on the big picture goals, do a speculative high level breakdown to inform an initial deadline and staffing commitment, but keep the precise scope flexible. For this part I find that separating out the aims from the goals is a helpful, e.g. Aim: to be sheltered from the rain Goal: build a roof Then you can adjust the goals (what kind of roof; materials etc) while keeping in mind whether the goals meet the aim, and whether the aims are still appropriate, and their priority too. Analysis is more difficult when the concepts are conflated.
genghisjahn 3y ago
I've dabbled with Monte Carlos sims for Sprints that have pointed tickets. I know 1 point ticket is sometimes a 3, rarely a 5. Sometimes a 3 is 1, and some tickets turn out to be 5s or even 8s. I build a simulator based on the fact that most tickets will be accurately pointed, but sometimes they will be different (usually more). I already know what our capacity is, so I run the simulator 10,000 times or so and get back info that lets me say, "It appears that we are X% sure we will complete all the points in this sprint on schedule." It was an interesting exercise but I didn't push it too far because I was fearful of the "you told me you were 95% sure it would be done. You had math and stuff!"

cratermoon 3y ago

> accurate estimates are unwanted In my career I've learned that estimating usually boils down to a game involving guessing what the customer will accept, while the customer tries to figure out what they want. Dig deep enough, and there's usually a dependency like "it needs to be done before X", but when X will be done is also imperfectly known, so it's a tangle of dependencies. The cases of hard dates usually involve businesses dependent on seasonal, holiday revenue or scheduled events like sports or entertainment touring schedules. Estimating for those is much easier, because the game becomes one of figuring what can be delivered by the date(s) in question. Regulatory changes or fiscal timelines are usually not as fixed as they are believed, because there's lots of ways to paper a path over delays, although its costs money and business don't like that.

dasil003 3y ago

“Telling the truth” implies two things: that the actual effort needed is fixed, and that you know it. In practice I’ve found neither of those things to be anywhere close to true for large projects. Furthermore the pursuit of accuracy by doing finer and finer-grained estimates and then rolling them up can waste a lot of time because it provides fodder for bike shedding while missing the forest for the trees. I can’t count the number of times I’ve seen this process lead to a total train wreck. What works better is to be very clear on the big picture goals, do a speculative high level breakdown to inform an initial deadline and staffing commitment, but keep the precise scope flexible. Then get right into prototyping and building, attacking the areas of largest risk and refining the requirements as you go. You only should have fine-grained plans for the next 2-3 months with the rest of the roadmap intentionally being flexible, save for any key milestones that are needed to ensure progress to the high level goal. Of course this requires deep expertise with cross-functional influence and bi-directional trust with management, but if you don’t have those things big projects are fucked regardless. In that case your best bet is hunkering down with some agile methodology as a shield while looking for a better job.

digging 3y ago
I find my biggest hurdle with estimation is often one small requirement which turns out to require a large amount of work. Like, "have this element behave in [unique way] on this page." Ok, well, that element was never even built to be touched individually, let alone have custom behavior. So now it's actually doubled the development time. This is something which can usually be caught during estimation, but occasionally it isn't something you're going to notice until you're actually digging into the code and implementing it. And if you're going that deep during estimation, you're already practically building the thing, so estimation is now taking up a significant amount of time and effort. I am not a super experienced dev, but I haven't really seen a way around these issues cropping up often enough to make estimation feel close to worthless. (that is, it's unreliable often enough that it's unwise to couple any timeline too closely to any estimate)
brigandish 3y ago
> What works better is to be very clear on the big picture goals, do a speculative high level breakdown to inform an initial deadline and staffing commitment, but keep the precise scope flexible. For this part I find that separating out the aims from the goals is a helpful, e.g. Aim: to be sheltered from the rain Goal: build a roof Then you can adjust the goals (what kind of roof; materials etc) while keeping in mind whether the goals meet the aim, and whether the aims are still appropriate, and their priority too. Analysis is more difficult when the concepts are conflated.

genghisjahn 3y ago

I've dabbled with Monte Carlos sims for Sprints that have pointed tickets. I know 1 point ticket is sometimes a 3, rarely a 5. Sometimes a 3 is 1, and some tickets turn out to be 5s or even 8s. I build a simulator based on the fact that most tickets will be accurately pointed, but sometimes they will be different (usually more). I already know what our capacity is, so I run the simulator 10,000 times or so and get back info that lets me say, "It appears that we are X% sure we will complete all the points in this sprint on schedule." It was an interesting exercise but I didn't push it too far because I was fearful of the "you told me you were 95% sure it would be done. You had math and stuff!"