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

How I estimate work

seangoedecke.com

Post reply on HN
Print view View original

201–210 of 326 posts

Re: How I estimate work

#201

Post by n4r9 »

crazygringo wrote: post #174

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…

What is the benefit of estimating points rather than days? Feels like you're still ultimately estimating days in the end.

Re: How I estimate work

#202

Post by n4r9 »

xn wrote: post #71

Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two months? Is it going to take more than two years? If you can answer these questions, you can estimate using a confidence interval. If the estimate is too wide, break it down into smaller chunks, and re-estimate. If you can't break it down further, decide whether it…

What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.

Re: How I estimate work

#203

Post by bogeholm »

Fire-Dragon-DoL wrote: post #197
crazygringo wrote: post #174

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…

Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points. Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work. If you look at all those properties together, story points are completely useless. The only moment time…

> The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful.

I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on).

You could assign relative complexity based on a number of things:

- number of integrations to other systems, - is the area well known to the team, - is the code well tested, - is CI/CD set up, - do we need a lot of alignment or can we just get started, - etc.

So you’re not estimating time, but complexity or hardness.

Then, supposing you have a stable team, you can go back six months and find out “we do on average 90 points per month” or similar

Re: How I estimate work

#204

Post by lucketone »

crazygringo wrote: post #174

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…

How single estimate accounts for different ability of each team member? E.g. Somebody new joining in will need more time.

Re: How I estimate work

#205

Post by stavros »

loloquwowndueo wrote: post #154
wreath wrote: post #126

Earlier quoted context omitted.

Why do that if your competitor already has it? I'd just go talk to the competitor instead. If you aren't able to ballpark when the feature will be done, why should I trust you will once I pay part of the price?

If the competitor already has it why are you talking to me? :)

Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.

Re: How I estimate work

#206

Post by crazygringo »

Fire-Dragon-DoL wrote: post #197
crazygringo wrote: post #174

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…

Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points. Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work. If you look at all those properties together, story points are completely useless. The only moment time…

> Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.

Literally none of that is anything I've ever encountered on any team.

They're not specific to a person, they're to a team.

They have nothing to do with the smallest task ever faced.

They are obviously for summing and are obviously units.

They effectively get translated into time in the sense that the team has a history of delivering an average of n points per e.g. 2 weeks.

Re: How I estimate work

#207

Post by crazygringo »

lucketone wrote: post #204
crazygringo wrote: post #174

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…

How single estimate accounts for different ability of each team member? E.g. Somebody new joining in will need more time.

Estimates are for the team, not for an individual.

As the team grows and shrinks, the number of points delivered per sprint are expected to similarly rise and fall. A new person joining will likely take time to ramp up the number of points they're contributing.

Re: How I estimate work

#208

Post by wiether »

publicdebates wrote: post #191
wiether wrote: post #188

Earlier quoted context omitted.

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.

Are you sure? I thought it was Renoir or Batut, or Bresson, or perhaps Watteau, who, when asked for his most useful advice to a new artist, famously uttered this short and mysterious phrase. Could have sworn LaBeouf quoted it in an interview after he collaborated with artist Cantor on their magnum opus.

It could be a niche quote in an art history book, but it could hardly be qualified as a saying.

I asked around since my first comment and not a single person knew about it.

Re: How I estimate work

#209

Post by Fire-Dragon-DoL »

bogeholm wrote: post #203
Fire-Dragon-DoL wrote: post #197

Earlier quoted context omitted.

Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points. Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work. If you look at all those properties together, story points are completely useless. The only moment time…

> The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful. I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on). You could assign relative complexity based on a number of…

An estimate is composed of two parts:

    - Time
    - Risk of being wrong
When you do what you just said "I am not estimating time, I'm estimating risk".

"This will take between 1 and 3 days" gives you both: the risk (complexity, hardness) which is represented by the gap, and time: how long it takes.

When a non engineer asks for an estimate, they usually mean one of these two things:

    1. How long it takes?
    2. Have you had experience with something similar before?
The second one can come also through the question "how challenging do you think that is?" To which we answer "easy but long" "hard" (never done it) or things like that. That's easier to answer, but doesn't translate to dates.

For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.

Re: How I estimate work

#210

Post by Fire-Dragon-DoL »

crazygringo wrote: post #206
Fire-Dragon-DoL wrote: post #197

Earlier quoted context omitted.

Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points. Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work. If you look at all those properties together, story points are completely useless. The only moment time…

> Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points. Literally none of that is anything I've ever encountered on any team. They're not specific to a person, they're to a team. They have nothing to do with the smallest task ever faced. They are obviously…

Every person I met gave me a different statement, so I don't fail to believe you, it's just that the definition of story points is different for everybody
Post reply on HN