'When is that thing going to be done?'

This is a practical guide for answering the question, "when is that thing going to be done?" Right up front, let's be clear that our numbers will be bullshit. That's okay, they're just informed guesses. We're not trying to predict the future, we're trying to make a reasonable prediction. It's planning season, the spreadsheet has to be updated by Wednesday, no one gave us time to even design the damned thing yet, so we just do not know.

The first part of planning is generating tasks and estimates, and this part of the process has been discussed to absolute death and 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.

This post is about how to turn that list of estimates into a date you can give to that person standing in front of you with a spreadsheet, so that they can immediately promise that date to your VP.

Types of buffer

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.

In my experience, I find that even a very experienced team doing something it's 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.