Estimates are a controversial topic in some software circles to the point there’s the #NoEstimates movement advocating for ditching them altogether. I think asking when estimates make sense helps to bring out context-dependent nuance missing from the yes-no perspective. Let’s put that discussion aside, though.

Sometimes we must estimate and in those cases we’d like to produce something realistic without spending an inordinate amount of time on the task. That’s where Power Estimation comes in handy.

The Power Estimation Method

The method relies on a table with rows corresponding to tasks being estimated and columns to types of work to perform on each task. Let’s see how this table is constructed in practice.

First, list all types of work relevant to the project, i.e. design, frontend, backend, writing automated tests, manual testing, mobile development, infrastructure, documentation and so on. Figure 1 shows an example table before any tasks were put into it.

Next, break the work down into an arbitrarily hierarchy of tasks. I usually think in terms of milestones, epics, features, and use cases. A slice of an example hierarchy may look like this:

• Milestone: MVP
  • Epic: Account Management
    • Feature: Registration
      • Use case: Successful registration
      • Use case: E-mail already taken
      • Use case: Password too weak
      • Use case: Account already exists
    • Feature: Log in
      • Use case: Successful log in
      • Use case: E-mail doesn’t exist
      • Use case: Invalid password
      • Use case: Account locked

The third step is the actual estimation. It’s subjected to three constraints:

1. Only powers of 2 are allowed. For instance, 4 and 8 hours are allowed, 6 hours is not.
2. Each task should get a power-of-2 estimate for each type of work. For example, “Successful registration” may need 30 minutes (2^-1 hours) on the backend, 1 hour on the frontend, and 30 minutes writing automated tests.
3. If unsure, overestimate. If you can’t decide between a 4 or an 8 then make it an 8.

Lastly, add up all estimates to produce the total estimate. The following table illustrates the method on a bunch of features. Let’s proceed to discussing the rationale behind the method.

Rationale

There’s a single insight behind the method: smaller chunks of work yield more precise estimates. If you think something will take 15 minutes then you’re more likely to be right than when you think it’ll take 3 months. The conclusions are twofold.

First, breaking tasks into subtasks increases accuracy. This is usually done by splitting work into milestones, epics, and features (or any other hierarchy). The problem is the resulting tasks are often still too big. That’s where types of work enter the scene. Even when a task cannot be meaningfully divided into smaller product increments, it can still be broken up into backend, frontend, and other subtasks which then can be estimated.

Second, larger estimates cannot have much precision so differentiating between a 15-hour and a 16-hour task is false accuracy. It’s avoided by allowing only powers of 2 which, when coupled with erring on the side of larger estimates, also ensures enough buffer for unexpected difficulties.

Limitations

The Power Estimation method is a heuristic I developed working as a fractional CTO and independent product engineer. The method proved its immense practicality but we need to be cognizant of its limitations:

• There’s no underlying formal statistical model so its results should be taken with a healthy amount of skepticism.
• The scope of work is assumed to be well-defined.
• Dependencies between tasks aren’t explicitly accounted for.

Closing Thoughts

Estimates are controversial in some software circles, yet are often warranted, especially in client work. I used the Power Estimation method successfully in multiple projects with reasonable accuracy. All it takes is a spreadsheet and a bit of time. I suggest you give it a try the next time you need to estimate a project.