I’ve gone into depth about engineering estimates. I shared how I do Technical Research, and then asked Product Habits readers about engineering estimates and shared your findings.

By now, we all know that engineering estimates are a heated topic.

People have very strong opinions and would sooner die than give up on using their “tried and true” process. So, you can imagine why I was nervous to share my own thoughts about engineering estimates. One of our lead engineers said this to me the other day:

“Hey, so Hiten. I’ve been reading your Product Habits emails. Actually, everyone on the team has and we’ve been talking about it in Slack. Are you, um, trying to start a war?”

It’s that important to people.

Last week I went into detail about my nightmares using no estimates, Agile, and of course the frequently used buffering of estimates. I even considered not sending it out because this topic can get so heated.

Challenges with engineering estimates are something I personally come up against nearly every week with the companies I advise and help. Even though I’m confident I’ve found a better way in the last few years, I was ready for the backlash.

As soon as the email went out last week, I sat watching my inbox, Twitter and communities like Hacker News, nervously waiting for frustrated responses.

But instead, I got the exact opposite. Email after email and tweet after tweet from people who had been experiencing the exact same challenges as me and were ready for their veggies.

“You are in my laptop – I swear!!!…I’ve printed this and will keep this on file so that each new team member going forward has access to it. It’s that important.”

“OMG this resonates more than you know. GIVE ME THE VEGGIES!”

“I had so many ‘ahh. so i am not the only 1 with these issues’ moments while reading this post.”

One person was so excited for the next email, they shared this photo of Cookie Monster actually liking vegetables:

Let’s face it, we all have estimates baggage. That’s why we’re so hungry for our vegetables.

We’ve tried lots of different estimates frameworks, but none of them actually worked. First, a major engineering challenge crops up. Then another thing you didn’t see coming hits the team. Suddenly tasks that were meant to last a few days slip into weeks and even months. You ask yourself, how can there be five issues at once that we didn’t catch?

Now there are two factions. Two armies at war within your company: Product vs. Engineering. Everyone is pointing the finger. And engineering typically becomes the scapegoat for delays. Estimates they provided get used against them.

“But you said it was going to be ready by Monday.”
“Why didn’t you deliver on time?”
“What went wrong?”

No wonder so many of us have PTSD from estimates.

When people use the most popular methods for estimates, unrealistic expectations get set for the team. Expectations that just can’t be met.

But it doesn’t have to be that way.

Engineering estimates are meant to take the guess work out.

With estimates, you’ll know how much effort each initiative will take before it gets started. Your plan will be based on technical research, not on guesses. Surprises will be a thing of past. As will communication gaps.

Tradeoffs are decided early based on customer needs and Product goals. And future implications get considered in coding decisions. Plus, the right tasks get worked on at the right time.

And they’re good for engineering too. Estimates mean less wasted time, less frustration and less wasted code. They actually help eliminate finger pointing and encourage team ownership over goals and the delivery of those goals.

The process of estimating gives engineering visibility into why the work matters so they can focus their efforts on things that actually impact the business.

Product can then go worry about what needs to be built instead of worrying about how to actually build it.

When engineering estimates are done right, the whole team works together to accomplish a shared vision. Everyone knows exactly how long each task will take before it gets done. And it gets done in that time! Ship dates are hit. And you’re actually excited to build the next feature! The team is happy and gets along. And customers are too!

I’ve got a framework for doing engineering estimates that really is like eating your vegetables, and your whole company will be healthier for it. You’ll need to do the work up front, but the payback is tenfold. And you’ll be able to do it without losing your sanity.

What You Can’t Do With This Framework

Here are a few things you absolutely won’t be able to do with this estimates framework:

1. Watch over engineering – You won’t be able to play the part of Big Brother. This framework is not about micromanaging people’s work. You’ll need to find another way to look over people’s shoulders.
2. Scapegoating – This is not a way to gather evidence to blame other people for shared (or your own) mistakes. You won’t be able to make engineering the scapegoat.
3. Rushing engineering – Woaw! So now that we know how to get accurate engineering estimates we can just build things in half the time! Nope. This framework isn’t about cutting down time to launch.
4. Scolding – You will not be able to tell someone in Engineering that they did a bad job because they missed estimates, unless you’re looking in the mirror.

Nobody really wants to be micro-managed, rushed, yelled at or feel like they’re the scapegoat when things go wrong. It’s not a healthy way to run a business, just like eating junk food isn’t the best for your health. So what is the healthy way?

The EAT Method

Ok, are you ready? I’m about to reveal the big secret.

Use hourly estimates.

Yes, you’re having a negative reaction right now. Hourly estimates? How in the world can that be done?

I get it. I had a negative reaction too at first. Now, I’d never go back.

The trick is embedded hourly estimates into a larger framework. If you use hourly estimates with the same processes you’re using now, you’ll run into all the same problems that Agile points and buffers cause. You’ll still have delays, miscommunication, and a frustrated team. The only difference will be that you’ve broken work into smaller pieces.

Hourly estimates work beautifully when you pair them with the right research and communication processes.

The three step method will get you alignment across your whole company. Clarity about what people are working on, why they’re working on it and knowing when Product improvements will get in your customers’ hands.

What that means for you? A motivated team, realistic ship dates and best of all, ecstatic customers who are shouting from the rooftops about the awesomeness of your product.

Now, let’s dive into the step-by-step process so you can start eating your veggies and create a much healthier company.

Step 1: Explore

Just like the Marketing/Sales divide is a classic breakdown point in organizations, Product and Engineering can also go at it.

If you’re having problems between the teams, the root cause is the initial exploration and planning on each new project. If you don’t do enough planning upfront, you’re setting yourself up to fail.

That’s why, getting to accurate engineering estimates starts with early communication from the Product team about what they’re thinking before they get too deep into it. When you’ve completed your research, you’ll hand off a detailed outline to your engineering team that breaks down what you intend to build.

Doing so much work up front might sound like busy-work at first but it’s actually the key to keeping your Product and Engineering teams working as a single team instead of separate fiefdoms.

Before you start writing any code on your new feature or product, start by exploring what it should look like with the engineering team.

First do technical research before any estimates get done. I shared a post about exactly how to do technical research. For every single one of my products or features, I now do a formal technical research round with my team. And I strongly encourage you to use this same method going forward.

The key to technical research is the initial Technical Research Outline you write to describe what you’re building (and why!).

Engineering needs the information in your outline before they dive into research so they can identify potential challenges and options to navigate them. You won’t need to get into the weeds yet, what you’re looking for is high level research to identify major challenges, roadblocks and initial tradeoffs that need to be considered.

Your Technical Research Outline should include the following information:

• Research findings – A high-level summary of the customer development and research you did and the key findings. What’s the core problem people have?
• Product overview – A description of the Product or feature you want to build.
• What needs to be included – The “must haves” required to make your idea work. What is the core piece of the product/feature?
• What doesn’t need to be included – What features or functionality might be coming soon, but aren’t important (yet) to add to the Product. This will help engineering focus on the must have items.
• Open questions – Questions you have that you haven’t yet answered relating to how to build the product. It’s OK to not know everything at this point!
• Initial mockups – If there were any quick sketches, designs or mockups created during research or to help explain the product, they should be shared via the document.

Once you’ve handed over the Outline, give engineering some time (a few hours to a few days depending on the project) to do research. They’ll be digging into technical considerations and options based on the information you provided them.

After engineering does their research, you should have a solid discussion to review their findings so you can have a good understanding of the initial tradeoffs and any challenges and risks.

Here are the exact questions you’ll have answers to by the end of your technical research:

• Speed – Will the entire project take too long? What parts are most challenging? What parts will be quick and easy.
• Initial tradeoffs – Are there tradeoffs you need to make? For example, deciding whether to build a core piece of technology in-house versus leveraging an existing API so you can release faster.
• Decisions – Are there critical decisions that need to be made before engineering starts building? For example, are there parts of the project where the engineering team is lacking experience that you should hold off on?
• Risks – What are the major risks that could trip you up? Is there a way to solve for the risks, or a way to minimize them?
• Resources – Do you have the resources you need (people, budget) to build the product/feature?

Step 2: Adjust

The work isn’t over yet. You’ve just started chewing your veggies, but there’s still more!

The exploration process from step 1 brings you Product revelations. You get to learn early on – before wasting any time – what the barriers, risks, and considerations are. This helps you build smarter as a Product team. You’ll have all the details you need to make decisions about what should and shouldn’t be built.

Were there any unexpected bumps in the road based on the technical research? The answer is almost always yes. You’ll work through these bumps during the Adjust step.

In the rare case that there were no unexpected bumps, you can jump straight to Step 3 and start the hourly estimates process with your engineering team.

You already created a Technical Research Outline to start the discussions with engineering. Now, based on what you learned from technical research, you’ll go back to your outline and start modifying it.

There are four key sections from the outline that typically get modified after the first set of discussions with engineering:

1. What needs to be included
After getting the initial findings from technical research, it’s common to remove items in this section. Descoping like this happens because you’ll now have a better understanding of approximately how long your requirements will take.

2. What doesn’t need to be included
You might learn that something you listed in this category is actually super easy, and your assumption that it was complex and should wait was wrong. In this case, you might decide to build a feature or some functionality out sooner rather than later.

3. Open questions
Most, if not all, of your open questions should be answered by this point. Document what you learned and then remove them from the open questions list. It’s also pretty common for Engineering to have discovered a few more questions that haven’t been answered yet.

4. Initial mockups
Once you’ve had an initial discussion with engineering and gotten their feedback you will be ready to start solidifying the user experience even more with updated mockups or designs. Depending on your product development process, you might even have final designs ready that you include with the updated outline.

The goal is to make updates to the initial outline to better meet the reality you learned about from engineering, plus match that with what you know about the customer and your larger aspirations with the product.

When you have a much better understanding of the tradeoffs that need to be made you can then weigh the new information against what you discovered from Product research about customer needs. Plus, your internal timelines and resources.

Once you’ve completed the adjusted outline and before anyone dives into estimating, have another discussion with the engineers.

The big question to ask your engineering team is:

Do you have enough detail to come up with hourly estimates?

Double checking the detail level with engineering is what makes the whole process work. Lack of discipline now means breakdowns later.

If the answer to the question is no, or I’m not sure, then you need to provide more information. Or engineering might want to go do a bit more technical research so you can all have clarity before you start building the product. Whatever your team needs, take the time now and get it.

Eating your veggies doesn’t come easy. Rinsing and repeating the process between technical research and making adjustments is what will prevent those nasty unknowns that typically come up once engineering starts building and it’s too late.

Step 3: Task

So now you just aligned with Engineering on an updated outline and you’re done with the technical research. Now we hand off everything to Engineering, let them break down the work into hourly chunks, Product starts working on the next feature, and everything hits the deadline? Right?

Just kidding!

Step 3 also requires a lot of collaboration between Product and Engineering if you want to keep your roadmap on track.

Product has all the context when it comes to what they want to build, for who, why, and what the customer’s challenges are. Most of the time, they only communicate a small piece of that, and, without realizing it, magically expect engineers to understand everything about the product and make it to spec and on time.

Meanwhile, engineering knows about all the tradeoffs, roadblocks, challenges and nuances. But they’ll only share them (or think about them) when asked.

The hourly estimates you receive from engineering will help you make decisions. You might choose to cut out certain functionality or even a feature based on how long it will take once it gets broken into hours. You’ve done a lot of the work upfront to make hourly estimates but don’t start cutting corners now, you still want Product and Engineering working closely together through Step 3.

First, Engineering should be asked to come back with accurate hourly estimates for each task based on your Technical Research Outline.

Accurate – as in if they say one hour, the task should take one hour.

How on earth do they do that?

Here’s a process that you can use to get hourly estimates regardless of the tool you use to plan:

• Engineering reviews the tasks and starts to break larger tasks into smaller ones that are no more than 4 hours each.
• Each task is estimated down to the hour (or less) and more technical research is done if something was missed during the previous steps.
• The hourly estimates are added to your project management tool and discussed between Product and Engineering.
• Estimates for tasks are then adjusted in the project management tool before work begins.

A common problem that people new to this process hit is engineering coming back with either really high hours for a task (over 4 hours a task) or blank estimates. This typically means the task hasn’t been broken down enough, or information is missing from Product or technical research that would allow engineering to break it down properly. With a little more information and planning, these tasks can get estimated. Remember, don’t take shortcuts even though you’ll want to. Your future self will thank you.

Here’s the key to getting the hourly estimates to stick and make a habit of eating your veggies.

You’ll hate to do it at first but once you do it a few times you’ll wonder why you didn’t do it sooner.

Create a feedback loop.

The feedback loop will tell you the difference between an estimate and reality. It’s not about blaming anyone for being off on their estimates or shipping late. It’s helping your team refine their estimates and get better over time.

Here’s a simple accountability process to help you implement the feedback loop:

• For every task, make sure you add the estimate for it before engineering’s work starts.
• To make the process seamless, build it into the Project Management tool you use. So in every card or task, add the estimated hours.
• When the task is being closed out, add the actual time it took to the card. Even if it was faster or longer than estimated.

Now you’ll be able to see which of your estimates were off and be able to diagnose why you had the wrong estimate. This process helps the team plan and understand how to make estimates more accurate. Just ask – “How long did it take in the end? Did it take longer than you expected? Why?”

Then you get to play detective to figure out what the challenge was. Where tasks were not broken up enough? Where were conversations missed. Where was technical research missed?

Ask why. It’s the only way you’ll get better.

Product development never ends. If you don’t constantly look to improve your processes, you’ll get stagnant and keep having the same problems over and over again. You’ll repeat the same mistakes while failing to deliver continuous value to your customers.

Common problems that cause inaccurate estimates:

• Surprises – Something unexpected came up during the middle of coding that got missed in technical research. Often this is a sign that technical research and planning was not deep enough.
• Scope creep – New additions to the scope were added in the middle of development that caused estimates to be off. A bad habit by Product managers. Caused by not aligning with Engineering before scoping out a feature in detail.
• Large tasks – Tasks never actually got broken up small enough, and as a result details were overlooked.
• Secret padding – Someone is adding padding just in case their estimates are wrong, so they keep finishing tasks early.
• Follow through – The estimate was done and task planned out, but the engineer didn’t follow the plan and decided to take another route.

So many engineers shudder at the thought of estimates.

There’s a chance that you’ll get resistance. After all, most kids don’t like eating their veggies despite how good they are for your body.

Push back on objections

Everyone has estimates PTSD, whether they say it or not. So when you introduce the method to your team, be prepared for pushback like:

• No way, Agile works just fine! It adds up to hours anyway.
• What about buffers?
• Why don’t you just do my job for me?
• I can’t estimate accurately to the hour. That’s insane.

When you dig into the why behind these feelings, it’s always about one thing. Engineers feel like they don’t have enough information to estimate because the task or group of tasks they are estimating hasn’t been broken down enough. They haven’t been given enough information or background, and conversations haven’t happened. Or worse yet, they’ve gotten used to the bad Product habit of scope creep.

That’s exactly what this process unlocks.

When I encounter pushback like this, I start by reminding engineers how bad they feel when there are delays. Or when they are working late nights struggling to get a handle on unanticipated challenges that came up or working on parts of a product that don’t actually matter.

I ask engineers who push back to try the entire process once and see how it goes. They quickly realize this process helps them get much closer to the customer. And as soon as tasks get broken down to precise 4-hour chunks and below, they realize a lot of the challenges they would have hit get handled early on.

Once you’ve gotten alignment between Product and Engineering on exactly what should be worked on and why, hourly estimates make you go deeper. They force you to have the tough conversations and the clarity on what needs to be built. They make you solve problems before you have them, so you don’t waste months on things that don’t matter.

Hourly estimates and the EAT method help you plan better. The more granular you can get, the better you get. The more veggies you eat, the healthier you are. The results might take some time to realize, but we all know the benefits.

If you don’t get down to hourly estimates, you’ll be back to square one and run into all the issues you’ve been having.