Hacker News Reader

Comment by optforfon | Hacker News Reader

I think you're talking about "first year of work" levels of experience. Estimation is hard - but a major goal of Agile development is to make it possible.

I thought the same thing as you, but a month ago someone explained it to me in a way that makes a lot of sense https://news.ycombinator.com/item?id=11641316

Actually a lot of the comments about this PDF can be summed up with "practice Agile development"

View on HN

How does that possibly solve the problem being discussed here? Are you the god who can define ALL tasks (in the agile meaning, a sprint consisting of a number of tasks) that a large project consists of up front, all the way to the end of the project 3 years later (for example)? Agile delivers because it doesn't attempt the impossible.

The problem seems to be that although companies want to pretend that they are all agile, the business and planning side really is not, because resources are not unlimited. So if you can't (even if admitting that it's faulty) put a number on time and effort, someone else higher up the ladder will do, and then it will hurt you.

I think that toolchains should have better support for estimated vs used time and then learning from that. You could classify tasks by field (DB, frontend, etc) and then calculate correction values based on past failures. Learning from wrong estimates seems to be even harder than estimating, because it hurts to admit that you were wrong, so some automated, blame-less version of it (per sprint or so) might be a good start.

My response was to optforfon's comment... I don't see how your response fits in in that context. optforfon's claim seems to be that Agile fixes the planning problem - which it doesn't, it simply limits planning to that which is plannable and (much more) easily foreseeable - small tasks right in front of us.

The tricky part is that agile is supposed to help those people sleep better. But it all kind of depends on your ability to explain to them how agile does that.

Of course budgets and deadlines has to be set. Agile is not a way to ban those, it's a way to allow them, even if forecasting is impossible. It's about saying, well at that date I can promise to have kept under budget, and will have something that more or less reaches the goal of the budget. It will not, however, be what anyone is imagining right now, let's have fun discovering what it'll be.

> 2. Maybe this estimation thing is impossible to get right, let's not put too much trust in being able to estimate accurately, but rather find ways of working that don't require estimating all work up front.

Isn't agile the #2 option quoted above? Agile in game development means being able to estimate how long it'll take to add fire damage to a weapon. It's not a means of being able to budget out 3 years worth of development, let alone hit a shipping date that far out.

I agree Agile is the way to address many of these issues. I think Agile is a way of working that doesn't try to estimate everything up front. Rather one or 2 short iterations at a time. If you're trying to estimate your whole backlog up front when you do Agile, you're back to waterfall realy.

Reply on news.ycombinator.com