Logo

dev-resources.site

for different kinds of informations.

A Simple Estimation Exercise

Published at
4/2/2022
Categories
agile
codequality
estimation
management
Author
jballanc
Author
8 person written this
jballanc
open
A Simple Estimation Exercise

The Task

How good are you at estimating how long a task will take? More importantly, how good are you at estimating the relative difficulty of different related tasks? Can you say, with some degree of certainty, if one task will take twice or three times as long as another task? Given a list of tasks, can you give an accurate estimate of which one will take the longest?

Here's a simple exercise we can try to evaluate your estimation skills. I will show you a picture of a sailboat. I need you to look at the picture and answer three questions:

  1. How many sails does the boat have?
  2. Is the boat sailing toward the left or the right of the picture?
  3. In the picture, is the wind currently blowing?

Based on this description of the task, how long would you estimate the task will take? Which sub-task will take the longest? Will any sub-task take twice or three times longer than the others to complete?

Do you have your estimates?

Are you sure?

Ok, then, I'll show you the picture...

... no peeking ...

... it's coming ...

... in just ...

... a ...

... bit ...

The (Big) Picture

Sailboat Stereogram

It's a schooner!

So, how'd you do?

That bad...eh?

The Problem With Estimates

What went wrong?

You might blame the inaccuracy of your estimates on being given incomplete information, but that's the very nature of an estimate, isn't it? You don't have to estimate how long it takes to bake a cake, because you have a complete recipe. If you are making an estimate, it follows that some information will be missing.

But what about your estimates of relative difficulty? Imagine your manager asks you how long each sub-task will take, and you respond that they should all take about the same amount of time. Then, after a day of staring at the picture, you go back to your manager and tell them that you'll need another day to finish the first sub-task. Based on your initial assessment of relative difficulty, your manager would justifiably freak out, expecting that what was initially estimated as a 5 minute task will now take 6 days!

Of course, that's not true. Once you can see the boat, it will only take 5 minutes to complete the task...

The Rate-Determining Step

One of my favorite topics from Chemistry is the concept of a reaction mechanism. If you have some chemicals that are reacting to form something new, you can dream up any number of different steps that the chemicals can take to get from start to finish. For each such mechanism, though, there will always be a bottle-neck or "rate-determining step". Regardless of whatever else might happen in the reaction mechanism, it is the rate-determining step that tells you everything about how fast or slow a reaction will proceed.

For any programming task, too, there are rate-determining steps: "once we figure out how to make a successful call to the API, everything else will be simple" or "we need to design the data model first, then we can get to work using it" or "if we can get the d@*! thing to deploy, then all the features should be working". Once these steps are complete, estimating how long everything else will take becomes much easier.

So, next time you have to estimate a task, in addition to giving a best guess for how long everything will take, try to identify the rate-determining step. You may not identify the correct one at first, but that's OK! You likely didn't guess that the rate-determining step for the task at the start of this was "making yourself go just a bit wall-eyed".

What's important is that, if you identify a new rate-determining step, you should communicate this to your manager and your team. This will accomplish two things. First, your manager won't have to freak out about how far off your other estimates might be, as there is only one rate-determining step. Second, your team will be able to come together and work, as a team, to clear the rate-determining step so that everyone can be more productive.

estimation Article's
30 articles in total
Favicon
Practical Approaches to Accurate Project Estimation
Favicon
The Importance of Accurate Cost Estimation in Construction Projects
Favicon
Emmision CO2 of a cat and a dog with python
Favicon
Top Project Cost Estimation Software Solutions for Accurate Budgeting & More
Favicon
Estimating Coding Tasks: What Could Go Wrong?
Favicon
Software Estimation Techniques
Favicon
Seniority in Tech: Beyond Technical Skills
Favicon
How we estimate tasks in Story Points
Favicon
Best Construction Estimating Services in USA Canada
Favicon
Nobody knows how to estimate software projects
Favicon
A developer's guide to estimation
Favicon
Seeing JavaScript Math.random Not Be So Random
Favicon
Flow Metrics Book Review
Favicon
My new POV on Story Points — a lesson in task estimation
Favicon
Predictability is overrated
Favicon
The Woes & Reliefs of Technical Recon
Favicon
Project Estimation - how to prepare for project implementation
Favicon
Rose bushes and story points
Favicon
How to release 2 years of unfinished code, the "Agile way"
Favicon
A Simple Estimation Exercise
Favicon
So do you expect me to write a blank check?
Favicon
Story Points means Relative Estimation, right? Not so fast.
Favicon
Three Bears Estimation
Favicon
The thing with agilists and deadlines
Favicon
Uncertainty increase development effort
Favicon
Estimates are not metrics
Favicon
Effective Estimation by Uncle Bob
Favicon
How to Become Better Software Estimator?
Favicon
Step by step estimation guide
Favicon
How to Estimate Anything Quickly

Featured ones: