Estimation

Individual contributors often have problems with estimations. The reasons are well-known: software is hard, there are too many details to take into account, and no one can consistently consider every aspect when estimating.

Because of these well-known problems, both individual contributors and their leaders tend to overestimate everything. It's only human to do so and, over time, teams stop trusting the accuracy of their own estimates.

The lack of trust in estimations is tragicomically common in our industry and no strategy works better than removing the process completely. If no one trusts estimates, what's the point, right?

The problem is that whoever asks for an estimate -- be that product managers, the marketing department, the actual customers (that's the best option!) -- this estimate or timeline is relevant to their work.

How do we find a balance between stakeholder needs and the hard truth that the estimation process is inaccurate, nonsense, and unproductive?

At my Latin class, the teacher would tell me virtus in media stat. It translates to "virtue stands in the middle".

It's a nice principle that always comes to mind when I discuss estimation process. You can design a process that removes estimations from your daily operations and still gives a somewhat accurate estimation to whoever needs it.

The key is to focus on what makes estimates hard: product development isn't predictable therefore our estimation capabilities are bad.

I invite you to take a minute and think about the situations in which you said to yourself "This feature takes X much time to complete" and you were actually right.

Done? Good.

I've spent a great deal of time thinking about this and I found that predictable features show the following characteristics:

• The effort is the smallest possible in the given context.
• During development, there was no back and forth between whoever specified the feature and whoever built it. The input was clear, no questions arose. After all, the feature was so small that the input was minimal.
• After the feature was deployed, there were no hot-fixes. The deployment was smooth, the system just kept working. After all, the diff was so small that the system almost didn't change.

Unfortunately, most features don't mark all these checkboxes.

They should though.

A feature built via "a small diff" that went from start to rollout without any problem is the perfect scenario.

The sceptical here would say: it's called perfect scenario because it never happens. I don't disagree with that, but I prefer to apply the following principle instead:

Strive for perfection, but accept that done is better than perfect.

The balance between an ideal and real world scenario is important and it should always be taken into account. Virtus in media stat.

In an ideal world, all features would require "a small diff", have a perfectly understandable input, and ship to production with no problems.

I know that the reality isn't so simple, but the ideal scenario is giving us a clear indication: small diffs are better than large diffs. They lead to short work in progress, and easy deployment. So striving for perfection in this context means:

What if all features we develop were as small as possible?

Well, all features would mark the three checkboxes I've just discussed... right? And that would result in a perfectly predictable flow!

Here is a trivial example:

• You have to develop a large feature.
• After some discussion, you break it down into 10 "small standard features".
• You know your "small standard feature" takes half a day.
• You are looking at a week of work.

Splitting guarantees predictability: if every single feature we build takes half a day, we know exactly how long anything takes.

The challenge moves away from guesswork and becomes getting better at breaking down work into small, coherent, deployable chunks of work. That's the process you want to use to mitigate the unpredictable nature of product development.

Focusing on splitting features has interesting side-effects on the communication infrastructure of a team. Continuously breaking down big features into small parts requires a lot of communication. It's a gym for empathy, too. It may be hard to break down a big feature into smaller chunks for a reason: be that the product angle, the design one, the technical feasibility, and so on. These situations help team members put themselves into other people's shoes and bring everyone closer. They can finally see each other's problems and then, with some practice, start anticipating them. Team members get closer and collaborate better if they have to break down features all the time. If that gets you a predictable flow, why wouldn't you try it? I personally see no downsides.