To estimate or not to estimate—that is the question
The problem with estimates is that they’re taken at face value. Yet, an estimate is not a commitment: sometimes, you run into a snag—an unforeseen issue—related to the specification or the codebase itself.
And that’s when we blow past the deadlines.
Consequence: developers protect themselves by giving estimates that are higher than necessary. If I estimate it’ll take me one day to do this, I say three. Three days—that way, nothing can go wrong for me.
Well, obviously, if I end up delivering after just one day, my manager will get used to it very quickly. “Oh, right, but that’s just Mathieu—he always sees problems that never actually happen, and when he says three days, he delivers after just one day. So it’s fine; I can safely plan for one day of development.”
So yes, but no, actually: back to square one.
Especially since if I deliver too quickly, I’ll come across as a rookie who doesn’t know how to estimate. So I’ll do it in one day (probably), deliver after three, and sneak in some personal projects the rest of the time. Every morning at the daily stand-up, I’ll say, “It’s coming along; we should stay on schedule.” Yeah, I’ve (survived) in the corporate world.
Should we blame the developers? Not necessarily: reread these lines from the beginning.
So how do we break out of this downward spiral, which is harmful to everyone?
It’s very simple: just stop making estimates. Tonight at 5 p.m., it’ll be 5 p.m. That much I’m sure of. The rest is just guesswork. Fifteen years of professional experience, and I still can’t come up with a reliable estimate. Or maybe I can—but only after the work is done 😉 Am I a bad developer?
At this point, any sane person is thinking to themselves, “Yeah, but I need a date!” Good point. Stay tuned.
Actually, doing away with estimates (the no-estimate approach) only works if the breakdown into user stories has been taken to the extreme: meticulous, like a jigsaw puzzle. Indeed, if each user story is really small (I don’t know exactly what that means, but let’s say half a day), and if I’m wrong and it takes me a full day, it doesn’t matter. It doesn’t matter because, across the entire set of user stories, the errors balance each other out.
And in the end, the only thing that matters is the number of user stories.
Does my manager want a date? All he has to do is count the user stories and apply whatever multiplier he wants. He can calculate it by looking at past development history. By the way, that becomes his estimate, rather than mine: a reversal of the estimation burden, so to speak 😚
Of course, this requires agreeing on what a user story is. We can’t stress this enough: splitting it into one front-end story and one back-end story makes no sense, because a user story must be able to go live and provide value to the user.
So the one and only real issue is breaking it down into tasks. And before that, the functional specification and requirements gathering. We could talk about this for hours, but enough for today 🙏