Hacker News Reader

Comment by drspacemonkey | Hacker News Reader

>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something, but I've only ever seen it turn into time-estimates-by-proxy.

These days, I only ever give estimates in terms of time scale. A task will take "hours", "days", "weeks", or "months". As long as it's within my power, my team will only ever estimate on that scale.

View on HN

This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it).

The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important thing to do.

My engineers know that they're expected to do that one project to completion, and we loop in other stakeholders (marketing, sales, QA, etc) progressively as we approach completion. Admittedly I work at a company of 20, but it works remarkably well, despite the absence of a "schedule"

> don't know how kanban it actually is, but that's what I call it

We also work with a Kanban-like methodology. Basically a pull system with a hard limit on WIP.

> If the answer is no, I ask why they care how long it takes if it's the most important thing to do.

Well... would you rather get $150,000 two years from now, or $90,000 next month?

You generally don't want to be making any decisions off ordinal comparisons.

You meet the PM/PO. They want to do Scrum, standups, retros, grooming, poker planning the whole thing.

Ask them to prioritize the tickets. Maybe they want some rough estimate to decide between some of them, maybe not (which is, suprisingly, in most case). During the same meeting you can groom the tickets.

The developers then start working on those tasks, when they are ready you release them according to your company policy and calendar.

By then everyone have forgotten about Scrum, management is amazed you release so much stuff, you can probably put all that in a one hour max weekly team meeting and everyone is happy.

I'm pretty sure that's applicable in a lot of pure player tech teams and quite scalable (I managed up to a 15 devs team this way but PR validation etc overtook the management part a bit much).

Wow, I wish the Fortune 10 company I work for had this kind of insight! The "agile" process I work under is causing horrible outcomes. It's basically a sweat shop operation is what it really is. I'm a tech lead and am always fielding questions like "why did this take so long?" It took so long because there was unexpected difficult A, B, and C, two of the four guys on team are mid-level devs and not senior level, and so I worked a third night this week to try and pull this off. The sprint plan never makes it past 1-2 days each sprint and then I catch a bunch of righteous indignation with phrases like "you committed to this" and crap like that.

"Why can't we better estimate these things?" Because when I give honest estimates I get threatened by my boss. Your process is not reality driven.

"Can we break this work down into smaller stories?" No, I can't break down the final integration of all the parts into a smaller story. Or more commonly, they told me we have "too many stories" and can't keep track of them all when we break them apart.

The best is when a Product Owner or other business type says "I'm not a technical person." Then why the hell are you working in a such technical business and calling the shots on stuff you don't even understand?

Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests.

Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends.

It drives me bonkers.

Quarterly planning is equally frustrating. I don't think we've ever had a quarter where we're on track three sprints in. Something always comes up, we pivot a bit, or our estimates were as uninformative as we all thought they were.

I had that too. Also they were negotiating down every last estimate while we were doing "planning poker" which was only a façade and was really us committing to unrealistic man-hours estimates unwillingly.

Or you get someone very senior in the company who rocks up in your planning meeting demanding to know the “real estimate”.

The real estimate is ‘as long as it takes’.

We have a great labor market. Don't be shy about quitting when things get cray-cray!

By we do you mean software engineering in general or bay area? Asking because most people commenting on hn tend to assume the entire universe is just the sf bay area.

Even non-bay area SWE in general is still much better than most other job types and probably much better when it comes to having a nice place to live anyway.

I'd say non-BayArea are relatively in the best position, because remote work always gives a chance for salaries much higher than local to you, while unlike the SF, costs of living won't eat most of what you earn.

Some people really do need to have the difference between an estimate and a commitment explained to them very carefully.

Similar but I’ll ask for a range which has a built in confidence level. A lot of developers are very reluctant to give estimates for various reasons but if the reason is that they don’t know where to start, I’ll do a thought experiment with them.

I ask first will the task take 20 years to finish and they usually laugh and say of course not. Then I ask what about 20 seconds and they laugh again. We keep going on both sides of the boundary until they stop laughing and it starts sounding more reasonable.

Then I have something to work with like 3 to 6 months which gives me more options. I can accept the risk or I can take other steps to reduce it or break it into more manageable bites. It’s not perfect but it’s worked pretty well.

Reply on news.ycombinator.com