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

251–260 of 326 posts

Re: How I estimate work

#251

Post by SoftTalker »

alexmonami wrote: post #196
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…

Our small team uses the Fibonacci sequence to estimate, and it works well for us.

Yep. My last manager would just ask "Is it a day, a week, a month, or a year?"

Re: How I estimate work

#252

Post by crazygringo »

SoftTalker wrote: post #250
crazygringo wrote: post #215

Earlier quoted context omitted.

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional…

I've never been involved in planning poker where everyone didn't converge on points = days at least in their own minds. "Hm, that would take me about a day, so that's one point."

Funny, I've never been on a team that did.

Otherwise, it would be impossible to have 20-point stories done in a 10-business-day sprint! Under the usual assumption that a single person is responsible for the whole story.

For the teams I've been on, a point has usually been more like a third of a day or half a day, i.e. 2-3 hours of uninterrupted concentration, and the 1/2 point card is used rarely. Sounds like you've probably used 1/2 point stories a lot more...

But this is why points are arbitrary. Each team decides whatever precise scale it wants. And it really depends on the type of work you're doing too -- whether the smallest stories tend to be things that are day-sized or things that are 2-hour sized.

Re: How I estimate work

#253

Post by netghost »

crazygringo wrote: post #248
mitthrowaway2 wrote: post #246

Earlier quoted context omitted.

If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.

Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision. The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size. I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, v…

I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc)

2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point.

That said, people tend to just collapse ranges, so I guess we all lose in the end.

Re: How I estimate work

#254

Post by xyzzy123 »

mactavish88 wrote: post #110
xyzzy123 wrote: post #76

Earlier quoted context omitted.

How would you decide between doing project (a) this quarter, or project (b)? If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI. To rationally allocate money to something, someone has to do the estimate.

The exact same way you'd treat any other investment decision. In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising. You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.

You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).

When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.

Re: How I estimate work

#255

Post by alfiedotwtf »

scott_w wrote: post #192
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…

There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?” I prefer it over estimating which feels more like asking the length of a piece of string.

The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(

Re: How I estimate work

#256

Post by Fire-Dragon-DoL »

crazygringo wrote: post #218
Fire-Dragon-DoL wrote: post #210

Earlier quoted context omitted.

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

I'm sure everyone has their own idiosyncratic interpretations, but I believe I've got enough experience to tell you that what I'm explaining is pretty standard. Here are literally the top two Google results for "story points" and they both seem to align entirely with what I said: https://www.atlassian.com/agile/project-management/estimatio... https://www.mountaingoatsoftware.com/blog/what-are-story-poi... I don't dou…

The definition of story points like the one I have mentioned has been provided by a certified scrum master and in a different context,by a certified scrum coach.

I appreciate your effort, but I don't believe there is any formal definition. It's redefined per team, it's redefined by the team too if needed.

So people want an estimate (uncertain) based on a number that's also nebulous. It kills me.

Use time ranges, you get a sense for risk AND have an estimated delivery date.

The adjustment people make with numbers can still be made on a per team basis using time ranges, I don't see why we have to use a proxy

Re: How I estimate work

#257

Post by [deleted] »

crazygringo wrote: post #218
Fire-Dragon-DoL wrote: post #210

Earlier quoted context omitted.

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

I'm sure everyone has their own idiosyncratic interpretations, but I believe I've got enough experience to tell you that what I'm explaining is pretty standard. Here are literally the top two Google results for "story points" and they both seem to align entirely with what I said: https://www.atlassian.com/agile/project-management/estimatio... https://www.mountaingoatsoftware.com/blog/what-are-story-poi... I don't dou…

[deleted]

Re: How I estimate work

#258

Post by crazygringo »

netghost wrote: post #253
crazygringo wrote: post #248

Earlier quoted context omitted.

Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision. The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size. I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, v…

I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc) 2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point. That said, people tend to just collapse ranges, so I guess we all lose in the end.

> 2-12d conveys a very different story than 6-8d.

In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly decide to do it or not if you had no idea if it could be 2 or 12 days. That's a big benefit of the approach, to de-risk that kind of variance up front.

Re: How I estimate work

#259

Post by jweatherby »

impute wrote: post #235

The only reliable way to estimate is to find another relatively similar project and compare it to that. You can say stuff like this new project is roughly similar in scope to Project X but maybe it's about 20% more complicated due to more scope so it will probably take about 20% longer than what Project X took. The key is to keep data on how long past projects actually took (which not a lot of organizations do). But…

In my experience that's where story points come in. "This comparable project took this number of story points, therefore should be similar, resulting in a comparable amount of time." The usage of story points help to adjust for complexity.

The story points are that data point in the past used to indicate the future.

Re: How I estimate work

#260

Post by nazgul17 »

At my previous workplace, we were developing a greenfield project, years in the making and kinda already brownish. Our managers were using our estimates to choose the right amount of work to fit into a sprint (fortnight).

Am I misinterpreting things or there is no overlap with the circumstances argued in the OP? Also, in that case, how do we make quality tradeoffs when all features are necessary for the end product?

Post reply on HN