Need to upgrade to the latest version of Laravel? Get instant, automated Laravel upgrades with Laravel Shift

Would you like some optimism or realism with your estimate, sir?

I've already made quite a lot of project estimates in my programming career. In these last three years, I've been estimating (and building) lots of features for one specific project.

Over time, some kind of dynamic has grown between our client and I. They ask me "Brent, would it take much work to build … ?", to which I always reply: "everything is possible, it just depends on how much you want to pay"; our client in turn always says "I know! But I need an accurate estimate first!".

Our client has told me several times that my estimates are actually pretty accurate, so I guess I must be doing something right, and I figure I'd share my process — based on nothing but my own experience — with you. Maybe it can help someone out there.


First things first, everything that's between 2 and 4 hours of work, I feel comfortable estimating with a buffer in mind. I usually multiply my original idea by a factor of 2, and that seems to result in accurate, small-scale estimates almost every time.

The problems start with features that take longer than a few hours. I don't think the human brain is capable of fully comprehending the scope of work at these scales, and this is a problem that's only growing more significant the larger the scope becomes.

Personally, I have a tendency to approach my estimates very optimistically: "if everything goes right, it'll probably take three weeks". And that's what I used to tell my clients. The problem with that approach is that they only hear "three weeks", and forget about the "if everything goes right" part.

I've now learned that nothing ever goes "just right"; and that there will always be unforeseen changes. I should account for those as well.

So I ask my client: would you like to have an optimistic or realistic estimate? In practice, my realistic estimate is simply the optimistic one, but multiplied by two or three, and represented as a range. For example: if my optimistic estimate is 2 weeks, I'll tell my client it'll take somewhere between 2 weeks and 4 or 5 weeks. If the optimistic estimate already spans months, I prefer to multiply by three, because the larger the estimate, the more things that can change.

I've been using this tactic for years now, and it seem to actually work pretty well.

What I think is key here, is that there's an open communication between my client and myself. There's a level of trust, and I feel safe to just tell them the truth, even though I know sometimes they might have liked a more optimistic version.

This level of trust and communication comes from working together for a couple of years though. It might be lacking at the start of a new project. That's why so many starting projects are under-estimated, and why there's almost always a point in the project where expectations need to be adjusted (with all the consequences that come with it, these usually aren't happy times in a project's lifespan).

So I try to ask clients up front: do you want an optimistic or realistic estimate? I tell them I know the realistic one will be better in the long run.

Noticed a tpyo? You can submit a PR to fix it. If you want to stay up to date about what's happening on this blog, you can subscribe to my mailing list: send an email to brendt@stitcher.io, and I'll add you to the list.