How I estimate work
seangoedecke.com
How I estimate work
1–10 of 326 posts
Re: How I estimate work
#2"If you refuse to estimate, you’re forcing someone less technical to estimate for you."
This is the perfect approach, given that estimates are top down and work to fill the estimate is bottom up.
"When I estimate, I extract the range my manager is looking for, and only then do I go through the code and figure out what can be done in that time."
Re: How I estimate work
#3"If you refuse to estimate, you’re forcing someone less technical to estimate for you." This is the perfect approach, given that estimates are top down and work to fill the estimate is bottom up. "When I estimate, I extract the range my manager is looking for, and only then do I go through the code and figure out what can be done in that time."
Except managers also have expectations of what can be done
Re: How I estimate work
#4The old guys in the 80's and 90's would say kiddingly multiply your original estimate time pi (3.14).
Re: How I estimate work
#5This resonated with me a lot, thank you. It more or less matches what I have experienced, and it’s good to see someone write this down in a fairly balanced point of view.
My favourite parts:
> My job is to figure out the set of software approaches that match that estimate. […]
> Many engineers find this approach distasteful. […]
> If you refuse to estimate, you’re forcing someone less technical to estimate for you.
Even after many years, I still find it distasteful sometimes but I have to remind myself what everyone gets paid for at the end of the day.
Re: How I estimate work
#6When I started in the early 90s, a wise old programmer gave me two pieces of advice about estimation.
1. When you consider planning, testing, documentation, etc. it takes 4 hours to change a single line of code.
2. To make good estimates, study the problem carefully, allow for every possibility, and make the estimate in great detail. Then take that number and multiply by 2. Then double that number.
Re: How I estimate work
#7The more I work in engineering, the more I agree with pieces like this which suggest that a large part of the job is managing politics in your workspace.
Re: How I estimate work
#8> I ask myself "which approaches could be done in one week?".
This is exactly how all good art is done. There's an old French saying, une toile exige un mur.
Re: How I estimate work
#9Estimation is an art, not a science. It's always going to be a judgement call by the engineers tasked with giving them to management. Taking all of the factors from this article and beyond can and should go into making that judgement call.
I always tell my teams just skip the middlemen and think of estimates as time from the jump. It's just easier that way. As soon as an estimate leaves an engineer's mouth, it is eagerly translated into time by everyone else at the business. That is all anyone else cares about. Better said - that is all anyone else can understand. We humans all have a shared and unambiguous frame of reference for what 1 hour is, or what 1 day is. That isn't true of any other unit of software estimation. It doesn't matter that what one engineer can accomplish in 1 hour or 1 day is different from the next. The same is true no matter what you're measuring in. You can still use buffers with time. If you insist on not thinking of your labor in terms of hours spent, you can map time ranges to eg. points along the Fibonacci sequence. That is still a useful way to estimate because it is certainly true as software complexity goes up, the time spent on it will be growing non-linearly.
Re: How I estimate work
#10I think the main problem in estimating projects is unknown unknowns.
I find that the best approach to solving that is taking a “tracer-bullet” approach. You make an initial end-to-end PoC that explores all the tricky bits of your project.
Making estimates then becomes quite a bit more tractable (though still has its limits and uncertainty, of course). Conversations about where to cut scope will also be easier.