Estimate Like a Pirate: Use a B.O.A.T.

It has been said that all issues come down to a failure of communication or a failure of expectation – or both.

Recently,  I have started to oversee more and more projects and have moved farther away from development work.  I’ve learned how critical it is to understand how confident people are about the expectations they are setting for  internal groups and external clients.  A gut check method I often use is: B.O.A.T.  This is a quick, back of the envelope way to evaluate an estimated completion date  in three simple steps and rules.

Let’s follow an example through the three steps.

Estimation: My client wants to know when we will finish the API interface.

Step 1: Pick a date!

Choose a date on which you plan to commit.  There are a variety of techniques to do this, but they are beyond the scope of this post.  If you do not have a date, write down your best guess.

For my API, I think it will be done by May 2.

Step 2: Write Boat

Write out – B O A T – Before, On-time, After, and Terrible

• Before means you will finish more than a week early.
• On-time means you will finish within a week of your desired date.
• After means you will be one or two weeks late.
• Terrible means you will be more than 3 weeks late.

If the desired date is less than a few months out, scale down (“before” becomes a few days early), or if it is over a year scale up (“before” is a few weeks early). Don’t spend much time thinking about the precise cut-off.

Step 3: Estimate

For each category estimate the percent chance that the project will be completed in the desired timeframe.

So for my API date, there’s a chance that we’ll finish early, but not a big chance. Plus this client often brings in new priorities, so that adds to the risk that it will be late.  But the work is well known so I do not see many big chances for it to blow up.  So I think there is a 20% chance we will finish early,  30% on time, 40% a little late, and 10% chance that we will be really late.

Keep the following rules in mind when estimating:

Rule 1: Do not be precise   

This is a gut check! There is no way you are  23.567% sure that the it will be on time.  Therefore, only use increments of 10% (e.g. 0% 10% 20% 30%, etc). I also like to allow a <1%, for the occasion when you can’t quite say 0%. The lack of precision helps prevent nitpicking at the margins; it is difficult to be nitpicky when moving 10% at a time.  

Rule 2: Forget about the details

Just like we are trying not to be to precise, don’t be too specific.  We often try and break big things down into smaller things that we feel like we can estimate, and then just add up those estimates, but that is not how life works. Just because one can swim 1.5k in 25 mins, bike 40k in 60 mins and run 10k in 35 mins does not mean they can do a triathlon in 2 hours.  This is your chance to think big.

Rule 3: No assuming away risks

I used this exercise with a Project Manager and he thought for a second and then started assuming. “Assuming we get the team we want, and there is no feature scope creep, and the designer delivers on time, and the third party vendor has good documentation …”

This reminded me a of an old economist joke:

An economist is trapped on a deserted island with some other people. They have nothing, but a shipment of canned foods.  The others turn to him and ask what should we do to get the food? He replies “Well first let’s assume we have a can opener.”

If we could assume away all risks, estimating would be so easy it would not be fun.  Think about the risks and the chance they will happen and how that would affect the chance of project/software delivery.  Keep the risks and put it in your estimate, that is where it belongs.

Ok, give it try and then we can talk about the different results.

Results!

There are a few helpful buckets into which results often fall. Let’s look at a few:

Sit down, you’re rocking the BOAT

Numbers like this…

show that you must re-evaluate your completion date. When a supermajority of your time is in B or T then your completion date should move in that direction. That second scenario can pose real trouble when a salesperson sees it and says “So you are telling me there’s a chance”.  Don’t give them the opportunity re-estimate.

If you can’t be early, you will never be on time.

If your estimate does not allow any possibility of being early like this…

then your completion date is too early. If you can’t be early even if all the stars align, then you’re relying on all the stars to align for you to just be on time. This is not the situation on which you should rely.

Think about your friends, the ones that are on time, they are always the ones that are early some of the time.

Commitment dates are not coin flips

Whenever your estimate has only a 50% chance of BO like this…

it might seem like you have hit it perfectly. However, it is a coin flip if your deliverable is going to be punctual or not.  People do not see a deadline date as a mean/median date, they expect a much higher chance at success.

In reality anything less than 70% in the B/O category is problematic, and for some clients I would even say 80% is on the edge.

You know nothing Jon Snow

When you have a really wide spread like this…

spend a bit more time on your estimates and see if you can nail down a few more details. This result is too broad and does not achieve anything.

Countdown to Success

When I see numbers like…

I feel pretty good! There is a good chance of finishing early which means it possible to be on time. But I have not been overly cautious, trying to estimate for every possible crazy thing that happens.

Crumble it up

Finally when you are done crumble up your B.O.A.T. and throw it away. It was there to judge your or your team’s estimate, to help you understand what is possible and what is just hopeful thinking. Now that that is done it does not have value.  If it sticks around it is likely to get you into trouble.  It is not a data point, it is an exercise.