Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poor developer estimates, a.k.a. guesstimation

alexefish.com

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Poor developer estimates, a.k.a. guesstimation

#31

Post by jacques_chester »

DanielBMarkham wrote: post #29

I've ran across this topic on 3 occasions in the last week in various forms: online, with a team, and on a LinkedIn board. Wow, must be something in the air. So here's the short version: 1) Agile relationships with customers boil down to Time and Materials. You're there working sprint-by-sprint doing stuff. Each sprint the customer and the team agrees on what it can do. The team decides, but the customer can always f…

> It's important to understand that by separating these concepts, you're not pressured to make time commitments when spitballing story difficulty. That's a good thing. Decouple those concepts and leave them decoupled.

I was taught by my software engineering professor to estimate software projects by size first and then to transform that into effort, then from effort into cost/schedule. He emphasised, like you do, that they need to be treated separately.

In his day size was projected in kSLOC or function points. These days you'd use story points. It's the same principle, in my opinion.

Re: Poor developer estimates, a.k.a. guesstimation

#32

Post by rfergie »

jacques_chester wrote: post #20
rfergie wrote: post #4

Also be aware of the selection bias when it comes to estimations. The companies A, B and C all put in estimates for a product based on similar premises. Company C gets selected because their estimate is the lowest. This could be because company C is the best and can do the work quicker but it is also possible that company C has just made a low estimate pretty much by chance. Estimates that are wrong (lower than the a…

I think you're mixing bids with estimates.

Yes, I think you are right.

But after reviewing my comment I think it is a point that is still worth keeping in mind.

The same kind of thing could happen internally within a company or even subconsciously within a developers mind.

Re: Poor developer estimates, a.k.a. guesstimation

#33

Post by jacques_chester »

rfergie wrote: post #32
jacques_chester wrote: post #20

Earlier quoted context omitted.

I think you're mixing bids with estimates.

Yes, I think you are right. But after reviewing my comment I think it is a point that is still worth keeping in mind. The same kind of thing could happen internally within a company or even subconsciously within a developers mind.

Yes, absolutely.

The problem is that business documents like a bid, an estimate, a goal, a plan and so on all share similar surface features. So it's easy to mix them up.

The classic is "that estimate is too high. Change the estimate".

Conceptually, an estimate is an immutable object. What you're really being asked for is a new estimate that is closer to a goal.

Re: Poor developer estimates, a.k.a. guesstimation

#35

Post by nradov »

jacques_chester wrote: post #10
onion2k wrote: post #2

This is actually a solved problem in some industries using a technique called "3 point analysis". I've no idea why it hasn't really caught on among developers; it's very useful. Essentially it goes like this: 1. Estimate the very best possible outcome. How long would something take if everything went to plan? 2. Estimate the very worst possible outcome. If everything that can go wrong does, how long will the task tak…

You've gotten to the first step, which is to provide 3 estimates. The next step is to break estimates into smaller parts, estimate them individually, then roll it back up to build a pseudo-statistical profile of probable outcomes. This is the PERT 3-point estimation technique. It's taught in every project management course in the world. It so happens that almost nobody uses it in practice, because it is a pain in the…

Build your tool as a plug-in for existing popular project management tools like Rally. No one will use yours if they have to enter user stories and tasks in two places. I would love a tool that could analyze best / middle / worst case estimates for tasks plus account for predecessor relationships between user stories and generate a probability distribution chart of possible release dates.

Re: Poor developer estimates, a.k.a. guesstimation

#37

Post by knodi »

Lets look at the definition of the word estimate.

estimate the cost: calculate roughly, approximate, guess; evaluate, judge, gauge, reckon, rate, determine; informal guesstimate, ballpark.

Of cause the developer is estimating because there are requirements missing. Hanse the word "estimate". Its more so the client doesn't to understand the word estimate.

Re: Poor developer estimates, a.k.a. guesstimation

#38

Post by nradov »

DanielBMarkham wrote: post #29

I've ran across this topic on 3 occasions in the last week in various forms: online, with a team, and on a LinkedIn board. Wow, must be something in the air. So here's the short version: 1) Agile relationships with customers boil down to Time and Materials. You're there working sprint-by-sprint doing stuff. Each sprint the customer and the team agrees on what it can do. The team decides, but the customer can always f…

That technique tends to break down when you have multiple agile teams working through a long, complex dependency chain to deliver a single project. It's also problematic when your customer has to make fixed schedule commitments to their customers based on your work.

Re: Poor developer estimates, a.k.a. guesstimation

#39

Post by ams6110 »

jacques_chester wrote: post #10
onion2k wrote: post #2

This is actually a solved problem in some industries using a technique called "3 point analysis". I've no idea why it hasn't really caught on among developers; it's very useful. Essentially it goes like this: 1. Estimate the very best possible outcome. How long would something take if everything went to plan? 2. Estimate the very worst possible outcome. If everything that can go wrong does, how long will the task tak…

You've gotten to the first step, which is to provide 3 estimates. The next step is to break estimates into smaller parts, estimate them individually, then roll it back up to build a pseudo-statistical profile of probable outcomes. This is the PERT 3-point estimation technique. It's taught in every project management course in the world. It so happens that almost nobody uses it in practice, because it is a pain in the…

It's turned out to be a deeper rabbit hole than I expected.

That's quite ironic, given the subject of this thread....

Re: Poor developer estimates, a.k.a. guesstimation

#40

Post by DanWaterworth »

pbreit wrote: post #34

I usually get pretty close by doubling the estimate and then cutting scope in half (or quadrupling estimate).

(half kidding) I have a similar system for making estimates:

1.) Think of a number,

2.) Double it,

3.) If it still sounds reasonable, go to step 2.

Post reply on HN