[13hours]

"To avoid schedule slippage, game developers need to spend more time to plan out all the work that needs to be done so that no tasks are overlooked when giving estimates. By planning out tasks, you can also estimate each task individually, and give a more accurate prediction, instead of an optimistic one."

When things don't work out according to the schedule, there are generally two reactions :

1. We didn't estimate well enough, we need to estimate better next time.

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.

I've seen that 1 gradually becomes 2 with experience (the experience of getting the estimates wrong every time).

[erickj]

so true. the estimation game can work well on time scales of up to a few months (like 2 or 3)... maybe

anything beyond that scale becomes the educated guessing game. no amount of analysis can flesh out every blocker that will be encountered. the deeper you go analyzing each task, the more the work just becomes doing that task.

[FatalBaboon]

The Agile problem goes deeper than that.

In a perfect world, it works as other comments point out: you get better at it, and everything is wonderful.

In real life, that estimate you gave last week becomes your duty. Unless you pinpointed it, you're out of schedule. If you're late, you look bad. If you're early, you get more work next time.

And there is no good way out, you can do it poorly but in time (which will only compound time as your poor solutions will introduce more work). You can do it late but good (but, well, late). You can give stupidly high estimates and then make your own secret schedule (and get found out eventually).

Agile is Fordism.

My advice: do not estimate timings. Have a list of things TODO, and have someone monitor expectations.

[knucklesandwich]

Here's the problem I keep coming back to with task estimation for implementing software. This is the absolute minimum description of what a software engineer's responsibilities are: Giving the correct set of instructions to a computer about how to accomplish a task.

Given that, a precise understanding of the time involved to accomplish a task requires knowledge of the time it takes to come up with the correct instructions + the time it takes to give the correct instructions to the computer. The time cost to give instructions to a computer is effectively linear in the size of those instructions (its whatever my typing speed is times that size), but the time cost to understand what those instructions need to be is effectively unknowable unless I've already got those instructions. It's sort of like the halting problem for people... if I knew how long it would take to come up with a reasonably precise version of them, you'd have a version of those instructions that could execute in some language (say some imaginary pseudocode language), or I'd have determined that the task is impossible.

I can keep a heuristic understanding of how long a task will take based on previous tasks I've completed (i.e. this task sounds similar to this previous one, which took me this long. I'll use that for my estimate), but there will always be some set of tasks for which I'm wildly wrong unless I precisely examine what's involved.

If it's better to estimate in a fashion such that I deliver everything I promise (and that we can have a planning session that doesn't last the entire sprint), I can pad my estimate by a large factor. In general, its easier to meet the criteria for this situation, but there will still be tasks for which my estimate can be wildly off. This can also lead to unhappy product owners who assume I'm trying to rig planning to excuse less work.

How do you come out of this exercise unscathed and with valuable information?

[optforfon]

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"

[LionessLover]

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.

[elcapitan]

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.

[CuriousSkeptic]

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.

[LionessLover]

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.

[lj3]

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

[13hours]

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.