###### By Jim Grey (about)

Maybe you’re one of the lucky ones.

Maybe you work in a shop that executes scrum well. Your team keeps the backlog well groomed, understands its velocity, and delivers working software sprint after sprint. Or maybe you work in an open research-and-development shop where the journey is as important as the result, and projects are always open-ended.

If, like me, you have to deliver software on deadline using a less-than-perfectly executed methodology, this post is for you. It’s going to give you a technique for knowing where you stand against your deadlines – a very useful skill that will reduce the chaos you experience and help your boss steer projects more successfully, both of which are good for you.

It is a method for implementing continuous reestimation, which I wrote about in this post. Read it to know why this will make you and your boss more effective.

Teams that have worked for me and have estimated using this technique have seen their projects come in within estimate about 80% of the time. The other 20% of the time, they learned important things about their work that let them estimate more accurately the next time.

Here’s the technique:

**Break down your work into tasks.****Estimate the tasks using a three-point formula.****As you work, reestimate every day.**

**Break down your work into tasks**

You might resist this step because in your core you know you will miss some tasks. **It’s okay.** This process honors that you don’t know what you don’t know. Just outline the tasks as best you can.

But think small, because you’ll be more accurate when you estimate more small things than fewer big things. Break things down as small as you reasonably can.

**Estimate the tasks using a three-point formula**

For each task, then, think of the following:

- If everything goes right on that task, how long will it take? This is the best case,
**B**. - If everything goes wrong on that task, how long will it take? This is the worst case,
**W**. - If a reasonable amount of things go wrong on that task, how long will it take? This is the likely case,
**L**.

Think for a minute or two about each task, but any more than that is probably overthinking it.

**Important:** Calculate your estimates in hours. Not days, not weeks, **hours.** There’s too much slush in days and weeks. Besides, in an 8-hour day you probably work just 6 hours on project tasks. You spend the other two hours in meetings, having hallway conversations, using the restroom, and being interrupted.

Here is where some magic comes in. Just go with me on this. For each task, drop B, W, and L into this formula and calculate the answer.

You’re weighting the likely case, but honoring the best and worst cases – and in one deft motion you take fear out of your estimates. What makes estimates bad is either unexpected things happening or *overpadding *for unexpected things happening. Thinking best/likely/worst helps you be more objective. And when you add up these three-point estimates for all your tasks, you get a reasonable cushion for the things that could go wrong.

Divide the number of hours by the number of hours per day or week you will work on the project. Lay that number of days out on a calendar; tell your boss that’s when you’ll be done.

**As you work, reestimate every day**

You are going to discover tasks you didn’t think of at first. And some tasks are going to take longer than you originally thought. When this happens, estimate the new tasks and/or reestimate the task that’s taking longer. Recalculate your end date and break the news to your boss.

Your boss ought to kiss you right then and there, by the way, because you gave him or her information early enough to do something about it – adjust scope, add resources, move the date, or tell you that unfortunately you are looking at some late nights. Hopefully the answer will be a, b, or c more often than d.

And every time you have to reestimate, you’ve learned something about your work that helps you estimate more accurately in the future.

“And every time you have to reestimate, you’ve learned something about your work that helps you estimate more accurately in the future.” This is more than just a coda in my mind. It gets at one of the core principles of getting better at estimation: feedback.

If you’re re-estimating daily, take a moment to think about how the day’s estimates played out and ask yourself the following questions:

– What parts of the work were faster or slower than estimated?

– What caused the work to be faster or slower? Break this down into specific root causes.

– Were the things that made it go faster one-off events, or should I start to factor them into my Best Case situationally? Globally?

– Were the things that made it go slower one-off events, or should I start to factor them into my Worst Case situationally? Globally?

If you’re really re-estimating frequently (and I assume Jim means quickly-upcoming work, or work for which you have important new insights, and not the entire project, yes?), then this exercise is short and the feedback loop is fantastic: you’re thinking about the drivers of the estimate before and after the work, and can quickly pick out patterns that can help you overcome chronic over- or under-estimating.

Rick, thanks for amplifying this. I probably ought to write posts about feedback and about the finer points of best/likely/worst, as really, this post is merely introductory.

“And when you add up these three-point estimates for all your tasks, you get a reasonable cushion for the things that could go wrong.” Well, you *should.*

Pro Tip #1: If you’re getting your 3-point estimate by thinking about your Best Case and Worst Case, then splitting the difference to get your Likely Case, that’s Estimation Fail.

A Best Case is limited and bounded: there’s no way it can take zero minutes. A Worst Case is (theoretically) unlimited and unbounded. You could encounter many problems or outright roadblocks and not finish for orders of magnitude longer than your Likely Case. (As a practical matter you adjust to these situations, that’s why Worst Case is only *theoretically* unlimited and unbounded.)

Your Likely Case is, almost always, going to be closer to your Best Case than your Worst Case. That’s where the reasonable cushion comes from: since you don’t always experience Worst Case, taking a little worst-case time from every estimated step creates a pool of time that realized Worst Case can draw from.

Pro Tip #2: An estimate is a guess. It has uncertainty. The greater the uncertainty of a task being estimated, the wider the range should be. The distance between your Best Case and Worst Case should be proportional to the uncertainty. No extra points for a nice, narrow B-L-W range if your actual time falls completely outside that range.