Live data from Hacker News

How I estimate work

seangoedecke.com

181–190 of 326 posts

Re: How I estimate work

#181

Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…

We do similar but sprints are somewhat flexible, more like versions. We chuck the features we want from the top of most needed, split into stories and estimate like you mentioned using brainstorming between devs and QA. Estimation happens by relatively comparing complexity of each new story compared to previously implemented stories, conservativy picking average one up if there is variance in estimates. QA is involved to determine how long it will take to test the feature or sometimes what uncertainty is there if this is even possible automatically.

In the end we have stable developer velocity metric and a really close estimate for each new version.

Re: How I estimate work

#182
I’ve long felt estimations are a negotiation. It’s not as much about how long it will take or how much it will cost, but what do you really need and what can you afford. Kinda like I’m helping someone buy a car based on their needs and budget, I’ll put together 3 “trim line” options:

1. Economy (bare functionality, prefer low cost and fast delivery over reliability and longevity)

2. Mid tier (good enough quality and reliable but no frills)

3. Luxury (all the bells and whistles)

The business will want all the bells and whistles of 3 but also the pragmatism of 2 but the budget and timeline of 1. So, they don’t actually pick themselves, I choose for them based on the circumstances and we negotiate the finer points.

Devs can gold plate the shit out of any project, but having a plan for #1 is helpful when shit hits the fan and the business needs you to pivot. More than that, it’s useful during the negotiation to illustrate the ramifications of shortcuts. It’s helped me more than a few times to avoid some really stupid decisions from panicking PMs and execs.

Re: How I estimate work

#183

Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…

I used to work for a company where we spent a day every 2 weeks doing this. And I had a headache at the end of the day every two weeks. Great that it works for you.

A day is crazy. In my experience, retrospective takes about 30-60 minutes, and estimation is usually 1.5-2 hours.

Does it take time? Sure. But what's the alternative? Not doing it is even worse, because you wind up with these endless never-finished "features" that turn out to be 20x harder than anyone thought, that engineers have sunk months and months and months into...

Re: How I estimate work

#184
post #175

I don't get the fight against estimates. An estimate is an estimate. An estimate can be wrong. It likely is wrong, that's fine, it doesn't have to be perfect. There is a confidence interval. You can communicate that. Very often something like "6-12 months" is a good enough estimate. I've worked in software a long time and I really don't get why many people think it's impossible to give such an estimate. Most of us ar…

For me the worst part is that I (and they) don't fully know what the person asking me from the estimate wants me to build, and usually the fastest way is to just build the thing.

Re: How I estimate work

#185

I think this post unveils a great truth that I never grasped: estimates are a political tool to decide what gets done and what doesn't get done. Thanks for putting it so nicely! One thing that I'd like to understand then is _why_... Why doesn't management use a more direct way of saying it? Instead of asking for estimates, why don't they say: we have until date X, what can we do? Is it just some American way of being…

Because manager have budgets that are translated in human hours/days of work. So they need to know the cost of each feature to decide which they're going to pick with their budget and deadlines.

Think of managers as kids in a toy/candy shop with a $X bill in hand.

If items don't have price, how are they suppose to choose? They want everything, but they are limited by their budget.

Re: How I estimate work

#186
I always have a lot of questions when I see this kind of articles, and I don't think any articles properly answer it.

1. What is different in software engineering with respect to any other work that require exploration?

The author mentions "it requires research, it's why it's impossible". But plenty of work requires research and people doing it are also asked to provide an estimate: writing a book, managing a complicated construction project, doing scientific research, ...

In all of this, it is also well known that time estimation is tricky and there are plenty of examples of deadline not met. Yet, it looks like that these people understand 1) that their estimations are guesses, 2) that still giving an estimation is useful for their collaborators.

I've worked in academic research, and famously, you sometimes need to write a document for a grant detailing the timeline of your project for the next two years. We all knew what it was (an estimation that will deviate from reality), but we understood why it was needed and how to do it.

I now work as researcher in the private sector, sometimes very closely with the software developers, sometimes doing the same work as them, so I have a strong experience of what it is asked. And I'm often surprised how often software developers are thinking that they are "special" when they have to deal with something that a lot of other persons have to deal with too, and how often they are all lost by this situation while other persons manage to go around it pragmatically.

2. Why is so many of these articles not reflecting in a balanced way on why people asked time estimates?

When the article comes to explain why developers are asked for estimate, the main reason seems to be "because non developers are idiots, or because of the checking box system, or because of the big bad managers who want to justify their role, or because it is the metric to judge the quality of the work".

But at the same time, if they need something, the same developers asks for time estimate all the time. This is just something needed to organize yourself. If you know that the builders will work in your home for 6 months, you know that you need to prepare yourself differently than if it is 2 days. And how many time a developer asked for something, did not get it in time, and did not conclude that it demonstrates the worker was incompetent? (I'm sure _you_ don't do that, rolling my eyes at the usual answer, but you have to admit that such conclusion is something that people do, including developers)

Why in these articles, there is never reflection on the fact that if you don't give any estimate, your colleagues, the people you are supposed to work with, and not against, don't have the information they need to work properly? The tone is always adversarial: the bad guys want a time estimate. And, yes, of course, we have situations where the admin becomes the goals and these requests are ridiculous. But on the other hand, I also understand that developers are asked to follow more process when at the same time they act like teenage-rebel condescending kids. I'm not sure what is the distribution, but even if it is not 50-50, it tells so much about the level of reflection when the article is unable to conceive that, maybe, maybe, sometimes, the developer is not the victim genius surrounded by idiots.

(in fact, in this article, there is the mention of "Some engineers think that their job is to constantly push back against engineering management, and that helping their manager find technical compromises is betraying some kind of sacred engineering trust". But, come on, this is a terrible flaw, you should be ashamed of being like that. This sentence is followed by a link to an article that, instead of highlighting how this behavior should be considered as a terrible flaw, frames it as "too idealistic")

Re: How I estimate work

#187
post #165
post #159

What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams). You don't need to estimate down to the minute, but you already know how many tickets/work items the completes at a given time interval with how many people in the team etc. This should give a rough estimate of…

How long does it take to do a crossword puzzle or play a game of chess?

Chess games usually have time limits, so pretty easy. Cross words depend on the size and difficulty.

Re: How I estimate work

#188
post #157

> 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.

> No results found for "une toile exige un mur". In case anyone else is wondering: The French phrase can be translated literally as "a canvas requires a wall", or less closely, "its boundaries are important for every picture". (I am not a native French speaker and just piecing this together with a dictionary.)

French guy here: never heard of "une toile exige un mur".

Not a single result in French also.

I know there's a (more popular?) saying that is very similar but can't remember it atm.

Re: How I estimate work

#189

U5jjtkfjjxhdu88939994999992889398 929 88889993uej72737377787383883998

> U5jjtkfjjxhdu88939994999992889398 929 88889993uej72737377787383883998

Now of course, my dear Watson, you should first suspect this to be a pattern, three groups in fact, separated by the two spaces, with the middle being a three digit number, perhaps an area code.

> U5jjtkfjjxhdu88939994999992889398 > 929 > 88889993uej72737377787383883998

But naturally, you would believe (and correctly so) this to be too obvious a clue, suitable only for the mind of a small child, not to mention the fact that these groups still produce nothing coherent.

You would then take note of the admixture of letters and digits, thus considering these boundaries to also be that of the grouping mechanism, not having yet forsook the spaces as delimiters.

> U5jjtkfjjxhdu > 88939994999992889398 > 929 > 88889993 > uej > 72737377787383883998

Yet this too, I'm afraid, would be merely a red herring, intended to placate the most simple minded of detectives, who, thus having congratulated themselves on such a brilliant deduction, fail to find anything more of meaning within this mangled mesh of evolved squiggles, yet nevertheless refuse to backtrack and admit their logical defeat, preferring rather to indefinitely postpone such investigations as "inconclusive" and requiring more evidence, so as to maintain their disguise as a competent student of human reasoning.

But you, oh no, you will not give up so easily, dear Watson, for you have seen practically miraculous epiphanies emerge at precisely the most unexpected of times, yes indeed, and you have thus all the reason in the world to march on just a meter more in this logical game of cat and mouse. And thus you notice next the repeats of digits and groups thereof.

> U5jjtkf > jjxhdu > 88939994 > 99999288 > 9398 929 > 88889993 > uej72737 > 37778738 > 3883998

Indeed, Watson, there are quite a few patterns within this group, and you endeavor to piece them all together, one by one, stitching them into a cohesive plop of meaning. You quantify them, count them, group them by every possible demarcator.

But you still find youself baffled.

And why, my dear Watson?

Why, it's elementary, good sir, quite elementary indeed: you failed to take into account the username and date of origin: o92992930999599, created 5 hours ago, with only two comments, this and another: "U878574890309987t366989283i487".

You see, my dear friend, there are only three explanations to this baffling mystery.

First, and least likely: this is the most advanced crypt I have ever laid eyes on. Preposterous! Bonkers! Absolutely mad! Simply look at the placement. It's a public web forum. There is no need for secrecy, nor for such a secretive communique.

Second, this account is merely a computer script, being tested for its verility upon the public forums of the net, to ensure it is functioning properly and soundly. Quite so, but no, these patterns were not computer generated.

Indeed not, for the patterns betray a certain command of the physical keybaord. Notice the repition of characters near one another yet not quite symmetric. It's as if the fingers danced across the keyboard, sometime here, sometime there, yet never in one spot for too long, now hopping from the left finger to a new key, now staying a while between two new keys, now hopping from the right to a new key, all the while intending to appear absolutely random, and failing absolutely, I migh add.

And this, my dearest Watson, has solved the great mystery for us! The clues have all added up to this one, great, pure moment of clarity:

Some kid's js high af n thought itd be funny to type random keys.

Re: How I estimate work

#190
Something I learned on this site: We're bad at estimating the average duration, but reasonable for the mean duration.

If you get 10 tasks of seemingly equal duration, 9 will go well and 1 will hit a reef of unexpected troubles and take forever.

So the practice of doubling is not that stupid. It leaves time in the first 9 to deal with the unexpected disaster.

Post reply on HN