[couchand]

Here's the thing: by the time you really know how long a feature will take to develop, you've done it. Until then you need to operate on an estimate. EDIT: I see you edited your comment to include the same sentiment while I was replying. Cheers!

People are bad at estimating, particularly if they're doing it alone, don't have much information or are trying to estimate absolutely. But we're pretty good at estimating relatively, doing it in groups (witness bean counting contests) and even with just a little information we can make improved estimates.

So the ideal task planning in my mind goes like this: the team gathers around the backlog to see what we think the next priorities are. Briefly we chat about each one, enough that everyone has a basic sense of what it is and no one is blindsided. We intentionally don't want to talk about it enough to implement it, just enough to get a sense for it.

The team then collectively estimates the size of each item with a hidden bid system: each person picks a number on an arbitrary scale (let's call it points) that only has meaning relative to the point values of the other things on the list. Once we have a handful, it becomes pretty easy to say "foo is harder than bar, but not as bad as qux".

[kabdib]

Cheers, indeed. (Sorry about the edit . . . it's the way I think). Happy we're in agreement.

Part of my problem with Agile is that my bad experiences have made me cynical and somewhat allergic to it. I react badly to being micro-managed and gamed by managers who are fundamentally out of touch with the reality of writing software, and who are interested in making the deck hands row ever faster so they can look good.