Estimation

"Most of what we do is R&D." -- An Intelligent Coworker

Lately (Fall 2018) our team at work has been working on refining and implementing our engineering process. One of our goals is getting better at estimation, and while there is a lot to say here I found that as an individual estimation remains about as hard as it always has been.

So I decided to try something odd. I've been experimenting with using the resolution mechanic from a table top RPG to assist me with estimation.

In the game any time you roll the dice you first consider two factors: position and effect. Position is a statement about your approach to the situation at hand and can be either: controlled, risky or desperate. While Effect is a statement about the results and can be: great, standard or limited.

Our goal as a team is to pick an arbitrary system of estimation, that we can eventually rely on as a team. So if we say that a certain task will be 4 points of effort, and we all agree that 4 points of effort is roughly two days of work and we routinely complete tasks to this estimate then we are on the right track.

So its all arbitrary but hopefully correct over time.

Getting approximate

With that in mind I decided to use position and effect to help me with getting better at estimation personally. So what am I doing?

First we have to come up with some parameters, I've highlighted risky and standard as that is the default position and effect in the game and a good baseline for this purpose as well.

Position

  • Controlled: I have done this exact thing, or something 99% like it before.
  • Risky: I haven't done this before but I know a lot of ways to solve it.
  • Desperate: I have not done this before, I do not know how to solve it.

Effect

  • Great: Solving this problem would make or save the entire business a lot of money.
  • Standard: Solving this problem would add substantial value, new functionality or fix a bug.
  • Limited: Solving this problem will automate a small task, or provide a quick solution to a small pain point.

Just like the game this gives us 9 combinations to work with.

  • Controlled/Great

  • Controlled/Standard

  • Controlled/Limited

  • Risky/Great

  • Risky/Standard

  • Risky/Desperate

  • Desperate/Great

  • Desperate/Standard

  • Desperate/Limited

Let's try it!

  • "We need you to install Wordpress and point a new domain at it."
    • Controlled/Standard
    • I've done this before, many times.
  • "The production Postgres database is deadlocking and we need to figure out why."
    • Controlled/Standard
      • Identifying the source of deadlocking. I've done this before, but this really only applies to the method of identifying the deadlocks, not the solution.
    • Risky/Standard
      • Solving the deadlocks. I've done it, but not very often. This case could be unique.
  • "We need to process customer data and apply Machine Learning to gather insights."
    • Desperate/Great
      • I have no idea how to this at this moment and it seems like it could add A LOT of value to the business.

So what have we done here?

This process adds a new dimension to estimation that I wasn't considering previously: my potential aptitude at creating a good estimate. Often when attempting to estimate I look first at the task, then at the choices available for creating that estimate and pick a number.

The old process was:

  1. Look at task.
  2. Look at estimation scale/points/units.
  3. Pick a unit to fit this task.

The new process is:

  1. Look at task.
  2. Assess task using Position/Effect.
  3. Look at estimation scale/points/units.
  4. Pick a unit, based on my Postion/Effect to fit this task.

The goal being that in forcing self-awareness of the situation and task while attempting to estimate I can hopefully create better estimates.