| Can't tell if serious or not. If a gozzlewog is something you haven't done before (and maybe nobody has done it) then you have much less data to go on. Coming up with an estimate for it can be really, really hard. Want to decompose it and estimate from there? Hey, you just fell into the trap. I wish I had a dollar for every time I've heard someone say "That turned out to be harder than I thought." And this is nearly always the case when you're doing something new. So you hem and haw and pad and you're late anyway . . . But my stand is that you're actually not late, you're actually on time and it's just that the estimate you made (or that someone made for you) sucked. You don't even suck at estimating because you can't reliably estimate something you haven't done before. Oh sure, small things. But not big things. Probably not even medium-size things. Imagine you're in a scrum planning session and someone says, "Hey, we tagged you for implementing Gozzlewogs" and you have absolutely no idea what a gozzlewog is, or maybe you read about them a while back so you're the person that people come to when they hear "gozzlewog." But you're on the hook for it, and they want an estimate and the answer of "I don't know" apparently isn't on the table. So do you: - Dig in your heels and say "I don't know" anyway? - Lie and say "Two weeks" because half of the dev team is in your shoes and doing the same thing, and you'll all slip together? Besides, next sprint it'll be the same bullshit, except with frumwidgets in addition to the deep, complicated and tricky stuff you discovered while investigating gozzlewogs. Now, clearly this is broken, and it's not even the fault of Agile, but rather the middle management that thinks developers are fungible and cog-shaped, and that everything can be decomposed and predicted, and that you can have a schedule with a granularity of days when your known unknowns are at the scale of multiple weeks. |
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".