Estimated time != Calendar time

Does the above sound familiar? If you have worked in an engineering department for any length of time, you have probably had this experience.

So what is going on here?

The problem is that there is a fundamental disconnect between the two people about what they are actually talking about. The product person thinks the engineer is talking about a calendar time estimate. But the engineer is thinking about an estimate in terms of the effort involved — one that is completely divorced from any specific calendar or scheduling considerations. This is one of the reasons why many projects are late.

In my experience when someone asks for an estimate and gets one, they immediately think calendar time.

“4 weeks? OK. If we start on March 1st, we are done March 28th. Great. Thanks”

Engineering Capacity

4 weeks of engineering effort may take 4 actual weeks on a calendar. Or it might take 6. Or 8. It depends on many factors. But the first and most important factor is engineering capacity.

Engineers don’t generally think about capacity. That’s typically the domain of people who manage projects, whether they be engineering managers, program managers or project managers.

Capacity is different from estimate fudge factors — amplifications which attempt to account for uncertainties such as technical risks, people risks, or any other unforeseen events. While fudge factors are about unknowns, capacity is about known effects on project schedules. We can know ahead of time at the beginning of a project how much capacity we are expected to have in the best case scenario.

Capacity is organization-specific

Capacity is fundamentally organization-specific. Some companies have more meetings than others. Some companies provide their employees more vacation. Some companies have professional development programs for their engineers. Many software companies also have hackdays on a regular basis. These are just a few common examples.

So let’s take meetings. Every company has meetings. What is the meeting tax at your company? Are there monthly meetings at various levels of the org that take up time for engineers? Think all-hands meetings, town halls, annual company meetings, team-building off-sites, etc.

Also important — when are the meetings? Are they at optimal times for engineering productivity? Consider that a poorly placed meeting can destroy engineer flow time if it’s at just the wrong time. A 1 hour meeting could mess up an otherwise productive ½ day depending on the task.

What about process? If you practice some form of agile process, you have ceremonies too. For example, one key to a successful agile process is having retrospectives. Your team will likely have one at least monthly. If you are a DevOps shop, you probably have some form of regular on-call review process.

Then there’s the things that need to be amortized over time. The most common example of this is employee personal time off (PTO). Beyond vacation time, PTO can include all kinds of other things, such as floating holidays, sick days, etc. PTO time varies across companies.

Another good example is professional development. Many companies offer this perk. This might mean each engineer can take up to, say, 1 week per year not actively doing project work. Another example might be annual or semi-annual events (e.g. a company kick off meeting that lasts 1–2 days). These can be amortized over the year with some simple math. All these will add up to a net cost you can average into each project.

Then there are the things that ebb and flow. Most tech companies are always hiring. This means many engineers are interviewing candidates on a regular basis, possibly as often as every week. In addition to the interviews, there is time to submit feedback, participate in candidate reviews, etc.

To be clear — there is nothing inherently wrong with any of these things. In fact, some are essential and many are highly beneficial. They help keep people motivated and attract great talent. The point here is just that they do have a cost and do affect your capacity to do actual work. And this all adds up.

Modeling Capacity

The idea is not to black hole this with crazy precision. Just get something approximate that has enough behind it to make people trust it is within a reasonable margin of error, say ~10–15%. Once you have a capacity, use it as a multiplier against your estimates.

A good capacity model will rely on the law of averages. You need to perform some analysis across your engineering organization and determine what is common to all or most teams. A conservative model may put capacity around 70–75% (For example, this is a simple model that might represent a typical tech company). Again, this is a conservative model. Capacity could be even lower, if your company has more meetings, more PTO, etc.

Project start date matters too

When a project can actually start matters too. If a project is expected to take 6 weeks but can’t start for another 2 weeks due to other commitments, then the ship date is at least 8 weeks away. Start dates are also prone to slipping as other things pop up. The things that pop up “in between” projects can easily eat up weeks and are typically tracked with less rigor. You can easily find yourself in a situation where a start date is months away!

So remember: the clock doesn’t start ticking until you actually start. Make sure stakeholders understand this. Often it is assumed the clock starts once something is communicated. Make start dates crystal clear.

Time of year matters

While a good capacity model would apply the law of averages to projects, there are some notable seasonal events that are worth considering if they happen to overlap with a critical point in your project:

• Holiday season
• Summer (more vacation)
• Conference season (the fall in North America)

It’s important to keep these in mind as well when you think about actually laying a project on a calendar.

Exercise: projecting an estimate onto a Calendar

It’s a good idea to have a quick and easy to digest capacity model handy in case someone gets sticker shock from the real timeline.

Let’s say you think your org capacity is about 70%. Now you have a project you estimate will be 4 weeks of effort for your team, and it’s expected to start on May 1st.

This means in the space of 4 weeks on a calendar, you will only get 70% of 20 possible days to get work done — that’s 14 days. You are 6 days short. It’s going to take you almost another 2 weeks (remember, you only have 7 days of capacity in 2 work weeks!) to make up that difference. In this scenario, a 4 week estimate is actually almost 6 weeks when laid on a calendar. It’s that simple.

Conclusion

There are a number of excellent books written on software estimation, but most people just get really basic things wrong. Make sure everyone is on the same page about what estimates actually mean. Then you’ll be well on your way to shipping things on time as far as everyone is concerned.

Thanks to Arup Chakrabarti for reviewing this post.

Originally published at https://leeorengel.com on August 13, 2019.