Squishy Task Estimates Are Tough

Alex Long
2 min readJun 27, 2021

You wouldn’t walk into a car mechanic and expect to know exactly how long a car inspection will take. If they don’t find anything you could be out the door in 10 minutes. 🎉 But if they do… you might need to reschedule brunch. 🥞

So what do you do when a client asks about a similarly ambiguous kind of task?

My client and I were recently going through our upcoming task list and when asked to estimate how long it would take to complete one item, I replied, “It’ll either be really easy or really hard.”

The task was to fix something that had broken in our pipeline, presumably by using a third-party service to delegate the work to. The indecisiveness of my answer came from the fact that we didn’t know if the service could actually do what we needed in this specific case or not. 🤷‍♂

If they could, we were golden 💯 — add a function call to their service in our code and walk away.

But if they couldn’t… well, it wasn’t clear that there was even any other way to fix the bug at all. 🤔

Basically, my answer in graph form was:

The next time a client asks you about a squishy task just show them this graph

The odds of it being either really easy (if the third party could do it) were equally as high as the odds of it being really hard (if the third party couldn’t). There was very little chance of any middle ground.

While this is an unsatisfying answer for planning purposes, it’s important to convey to clients the nuances behind tasks like this. Even if at the end of the day you still commit to a single estimate, e.g. “4 days of work”, making your client aware of the complexity can help soften the blow when things don’t go as planned.

👨‍🔧 And here’s hoping that the mechanic doesn’t find anything so you can go enjoy that brunch. 🍷

--

--