This post should take about 30min±2h

Part of development work is to make predictions about how long a feature will take to implement, or a bug to fix. It’s a foundational part…

Part of development work is to make predictions about how long a feature will take to implement, or a bug to fix. It’s a foundational part of calculating the value propositions of IT — it’s only in light of these estimations that project owners can decide whether or not to move forward with a plan, or scrap it in favour of other strategies to increase value.

A bit of work usually follows this path:

• Read the requirements on a ticket, understand what the client wants to implement and why

• Estimate approximately how long this task will take

• Discuss this estimate with the client

• Implement the work

It’s super important to be accurate with estimates. Not estimating correctly creates mismatched expectations, and generally misery all around.

However, not all estimations are equal. Given one stream of work such as “Redirect HTTP to HTTPS” and a server that has been implemented as infrastructure as code, I can give a very confident estimate of less than a day. However, given a more nebulous task such as redesigning a checkout or upgrading the core application, it’s much harder to estimate accurately.

Luckily, this problem is already known and solved! Thanks science. To express the confidence in an estimation, we can assign it a range with the ± operator. From Wikipedia:

In experimental sciences, the sign commonly indicates the confidence interval or error in a measurement, often the standard deviation or standard error. The sign may also represent an inclusive range of values that a reading might have.

For example

So, applied to our estimates it might look like something as follows:

Migrating the site to HTTPS

Migrating the site to HTTPS is a fairly simple task that has been implemented before in ${SIMILAR_ENVIRONMENT}. It should take 8h±2h

In this case, the estimate is between (8 — 2 = 6) and (8 + 2 = 10) hours. Expressed in a straight forward way: 6–10h

Upgrading the application from version 3 -> 4

Upgrading the application is a hugely complex task which has implications for all features. The application has had vast internal API changes, and it’s not clear how to re-implement some existing features. It should take 6w±4w

In this case, the estimate is between (6 — 4 = 2) and (6 + 4 = 10) weeks. Expressed in a straight forward way: 2–10 weeks.

The developer here very little understanding of this work. (This sometimes happens, it’s just the nature of doing new things)

Walking Home

The walk home is a straight forward task, which has been accomplished innumerable times before. However, there is a particularly interesting looking restaurant on the way, which might warrant stopping in. The walk home will take 30m±2h

In this case, the estimate is between (30m — 120m = -90min) and (30m + 120m = 150min). We can’t go back in time, so we’ll cap the simple estimate at 30min — somewhere between 30 and 150 minutes, then.

In summary

± is one way to express the confidence in estimates. I’m not super tied to this mechanism, but I think it is important to express confidence in all estimates. Sometimes things are not clear, which is fine — but we need to be up front about that.

(Also, FWIW this post took ~24 minutes).