Improving Our Estimation Abilities: Embedded Artistry's Approach

16 March 2020 by Phillip Johnston • Last updated 21 April 2020

After we shared estimation thoughts on Twitter, we received a question in the Embedded.fm slack group:

What do you guys do for estimates and how do you improve your estimates? Any resources to help understand estimates more or just helpful things in general?

Following our article on why we estimate, we’ve put together a series of articles where we approach estimation from multiple directions: the understanding of human biases, our practical approach to estimation self-training, practical lessons that we’ve learned from experience, and other approaches to estimation.

In this article, we share Embedded Artistry’s approach to estimation self-training.

Table of Contents:

The Basic Principles
Know Thyself
Know Why You’re Estimating
Understand the Problem
Document Assumptions
Feedback Cycle
Communicate
Summary
Further Reading

The Basic Principles

The basic principles of self-training in estimation are:

“Know thyself”
Create a feedback loop

We’ll explore how these two principles are applied to estimation self-training.

Know Thyself

We started this series with biases for a practical reason: they are the first step in understanding how your human brain operates.

Beyond that, the greatest asset in your ability to provide estimates for your work is knowing yourself deeply. You cannot improve your estimation abilities if you are not watching yourself, learning, and adjusting your behavior.

The baseline requirement for making an estimate is understanding how much time you actually work in a day and what you spend a time on.

Most of us make estimates assuming we will spend a full workday dedicated to the tasks being estimated. Unfortunately, we tend to dramatically overestimate our actual hours spent working in a week. During the work day, we have constant distractions, we’re browsing social media, spending time in meetings, answering emails, fixing bugs identified by QA before that release which is scheduled for tomorrow, spending time in the bathroom and outside, and eating lunch and often dinner.

To put this into perspective: at Apple, I was frequently only able to spend 1–2 hours per day on programming, which was what Apple hired me to do; the rest of the time was spent communicating and moving from building to building. Now, with Embedded Artistry, I regularly manage 4–5 hours a day on programming or writing.

For the past ten years, I have been collecting data on how I spend time at a computer using RescueTime (the free version is good enough). I can tell you that I spent 1,865 hours on a computer in 2019, and 296 of those hours were on activities I call “distracting”. I spent 24% of my time at a computer developing software, and 11% of my time was spent on social media (it pains me to say!).

Thanks to this data, I have a realistic model for how many hours I actually work during a week, and how my time is usually spent. I also have measured data that I can use to track improvements, such as reducing the time spent on social media.

Aside from knowing how you spend your time, you need to track your actuals and see how your estimate stacks up against them. At the very least, you should track your hours spent on an estimated task and compare to the estimate you gave once the task is actually complete.

We track time spent working on projects using Harpoon. Any project-based timer will work (including a sticky note with start/stop times); we use Harpoon to generate invoices for clients. From an estimation training perspective, Harpoon allows us to set hourly targets for an overall project and shows us how much we worked relative to the estimate.

The final tool we use for estimation training is simple: Excel. Whenever we need a detailed breakdown of tasks for a project, we generate a table in Excel with major tasks, dominant subtasks, estimates for completion, and due dates. We track actual time spent on each task, as well as start/stop dates. This data can be used to analyze our estimates and highlight points for improvement.

Without this data, we would have no way to tell how well we are doing with our predictions. We can only make improvements if we know how we are doing in the first place.

Know Why You’re Estimating

In a previous article on estimating, we highlighted that you need to understand the reason you are making an estimate.

You can’t provide a useful estimate without understanding why you’re being asked for one. If you do attempt to provide one without understanding the context, you risk giving an inappropriate answer.

Another important detail to keep in mind along these lines: estimates are not fixed commitments. You might choose to provide a fixed commitment based on an estimate, but that is not how most estimates are used.

Understand the Problem

Historically, whenever we’ve gotten an estimate terribly wrong, the primary cause was that we didn’t really understand the problem.

We’ve watched countless engineers and programmers hear about a task for the first time during a meeting, receiving only a one or two sentence summary of the problem without any context. After about 10 seconds of thought, they throw out an estimate off the top of their head. Of course that estimate is going to be wrong. Then, to make matters worse, we repeat this process for the remainder of the estimation meeting.

Estimating without understanding is simply making stuff up.

If you do not understand a problem, say so. Spend time researching, thinking, and coming up with a plan before you provide an estimate or schedule. Try to identify possible problems, alternate approaches, or solutions that can be purchased. Ask a colleague, or three, for input, because they might see potential problems or solutions that you haven’t seen.

Sometimes it’s important to deeply understand a problem to provide a high-confidence estimate. You can spend more time understanding the problem to increase confidence in your answer. Create multiple designs and figure out the tradeoffs between them, prototype solutions, or verify the approach with formal methods.

Matthew Eshleman shared an excellent set of questions to ask during software architecture, design, and coding. If you feel stumped, try working through these questions to make sure that you really understand the task at hand.

Document Assumptions

Whenever we didn’t understand a problem, we often made assumptions that were proven to be false during execution.

Whenever you find yourself making assumptions, document them. We document assumptions for projects and tasks in our Excel spreadsheet, and we even have a table of documented assumptions in our business plan. Revisit these assumptions whenever your estimates are off: I bet the error is related to an incorrect assumption.

At the very least, you have a sufficient explanation for why things went astray: “We believed X was the case, that turned out to be false. In the future, we will Y.”

Feedback Cycle

Continually refine your estimates (or the details of any plan) as you gain more information. It’s ok to be wrong: it’s an estimate. Things happen.

As Ruth Malan highlights, we continually adjust to the unanticipated throughout our lives. Estimating work is no different.

Our bodies aren’t simply reactive. We use anticipation – each step we take has very local anticipation that adjusts how we take the step, but also heads in a direction we have anticipated we want or need to go in. Again, if something unanticipated is in our path, we adjust. We have these many levels of anticipation and adjustment, all the way up to budgeting for our kids’ education, saving for college. We know that we have this balancing between anticipation and sensing and adjusting and anticipation.

Whenever a problem, roadblock, or deviation arises: note that. Adjust your plan. Later, analyze:

Is this a recurring or one-off problem?
Are you accounting for these types of problems when making your estimates?
Can an automated process be put in place to reduce the chance of an error in the future?

In other cases, you will identify “hidden” tasks that will impact the estimate you previously provided. Update the task list, give the new items values, and adjust your estimate to account for the new information.

Communicate

Once you’ve adjusted your estimate, plan, or schedule with the new information, communicate the change to your team immediately. Do not wait until the due date to communicate you are late. At that point, the rest of the team will be justifiably upset.

“The single biggest problem in communication is the illusion that it has taken place.”
–George Bernard Shaw

Be proactive, adjust to new information, and communicate changes immediately so the rest of the team can adjust too.

Summary

The approach outlined above is the basis of any self-training, not just estimation. We must know ourselves, our abilities, and our tendencies. We must have some type of feedback loop that gives us an indication of how are doing and what adjustments are needed. We must continually integrate the lessons we learn along the way.

We will never be perfect estimators. We live in an uncertain world, and there is always more to reality than we can see. That shouldn’t stop us from improving at the art. Most importantly, whenever we gather new information that changes our plans or estimates, we must communicate that change to the rest of the team.

In the next article, we’ll share practical estimation advice that we’ve picked up over the years.

Improving Our Estimation Abilities: Embedded Artistry’s Approach