When is that thing going to be done?

This is a practical guide for answering the age old question, "when is that thing going to be done?" Right up front, let's be clear that our numbers will be somewhat bullshit, and that's okay. We're trying to predict the future, and we're not going to get it perfect. It's probably planning season, the spreadsheet has to be updated by Wednesday, and no one gave us time to even design the damned software yet, so we just do not know.

As it turns out, "I don't know when you can have that" is a wildly unpopular answer with tech executives, so our job is to come up with a defensible engineering estimate that doesn't cause us to work every weekend between now and the promised date.

Generating estimates

The first part of planning is generating tasks and estimates, and this part of the process has been discussed to absolute death. I don't have a ton to add. Write down all of the work you know you have to do, and then make a wild guess about how many days or weeks it will accomplish you to do each thing.

Let's say this is my team's tasks:

# TURBO ENCABULATOR BACKLOG

1. Design the turbo encabulator (3d)
2. Prefabulate the aluminite (5d)
3. Tune the pentametric fan (1d)

So, great, now you have a list of stuff you know you need to do, and some guesses about how long it will take to do it. Should you just add up all your estimates and consult a calendar to the estimated end date? No! Absolutely not. You will not hit that date. Before you make an upwards commitment, consider the actual date by which you think you'll be done.

Guess at a final date by buffering

We're going to now attempt to guess about an actual date by which I can get the above 9 days of tasks completed. There are three types of buffer that you should consider before making commitments.

1. Your estimates are wrong

You're definitely missing work from your list. There will be problems that need solving that you haven't considered yet. There will likely be changes to the requirements that require rework. It's going to turn out that the Data Runtime Enablement team has a 48 hour SLA for PRs, I didn't get my PR out for approval until Friday, someone is on vacation, and my code isn't shipping until three days after I thought it would.

In my experience, I find that even a very experienced team doing something it has done before will still end up being around 30% soft on their estimates when they write down all known work upfront. In one particularly challenging case, I had a project take 3x as long as the original estimate. I usually start out with B = 1.33 and then have the conversation with myself and the team about how uncertain the work is.

Buffer One: known_work * uncertainty

2. You're not going to work on this project exclusively

If you have a week of estimated work, and a week to do it, don't expect it to be done in a week. You have meetings. You probably have to interview people. You're going to get interrupted by other tasks and projects. I personally find this easiest to think about in terms of, "how many days a week do I get to focus?" For a fairly normal team, I find that we work about 3/5 days a week if we're assigned full time to a particular project. The other two days are a wash of meetings and distractions.

Buffer Two: focused_days_per_week / total_days_per_week

3. Some days you won't even work at all

People take vacation. They get sick. They go oncall and spend a week straight listening to their pager beep. It's a clear mistake to forget to account for individual vacations and company-wide holidays. Anecdotally, I think this is probably part of the reason so many Q4 projects slip; in the US there are quite a few multi-day federal holidays, so the quarter is just short. Despite that, I see tons of plans that have three solid months of work booked in Q4.

Buffer Three: estimated_date + number_of_days_off

Putting it all together

Okay back to our backlog.

# TURBO ENCABULATOR BACKLOG

1. Design the turbo encabulator (3d)
2. Prefabulate the aluminite (5d)
3. Tune the pentametric fan (1d)

1. Apply the bad estimate buffer

That's 9 days of work, but I'm gonna guess I'm off by about 33%. So let's call our buffered estimate 12 days.

2. Apply the "we don't work only on this" buffer

Now we consider that I only expect to work on this project about 3 days a week, so I should expect that it'll actually take me 4 calendar weeks to get the thing done.

3. Apply the "some days I don't work at all" buffer

But hold on a minute, it's November, I'm taking a week off. That means that there's a solid week in here where I shouldn't expect to get any work done.

4. Guess a date to promise

So my overall estimate is that my 9 day project will land about 5 weeks out. Does it sound a little silly when you put it like that? Sure, it does. I get it. But if I made an error above, I'm not sure where it is. I've been watching people miss dates for about 20 years now, and I genuinely think this is an approximately accurate method for guessing at a delivery date.

I recommend turning the above into a rough spreadsheet. The spreadsheet is a throwaway document, you're not trying to keep it up to date, you're just trying to capture a point-in-time estimate so you can have a more or less reasonable guess about when that thing will be done.

What about projects with multiple people?

There's one area we've skipped so far, and it's how to apply this to teams. The only way this changes the buffers is that the third buffer gets divided by the number of people. This isn't perfect since the long pole task might be on the person taking the vacation, but we're just guessing here.

Conclusion

Your estimates are wrong. You're going to get randomized. (In fact, that's a big part of your job!) Don't sign up to do work when you intend to be on top of a mountain, hiding in bed, or hanging out with your family.