## DEV Community

Ryan Latta

Posted on • Originally published at ryanlatta.com on

# How to Estimate Anything Quickly

Estimating projects, huge ones, seems to be an activity that causes groans and protests. I understand why. Often there’s a tension between accuracy and knowing that they can’t be accurate. When confronted with estimating a large body of work, I employ a variation on affinity estimating that takes 10 minutes and gives a preview of where the monsters are hiding in the road ahead.

# Step One: Write Down the Stuff

It doesn’t really matter how you write things down or if they’re the same size. Just capture the work as the group understands it.

By the way, if you’re doing annual planning and doing multiple projects, you can also write the projects down and estimate whole projects.

Either way, this part will take roughly 5 minutes. Again, don’t worry about getting it all perfect. We’re not aiming for perfection.

# Step Two: Pick One Obvious Item

After you have all the items, ask the group to pick one that is more obvious to estimate. We’re looking for the one the team seems to know the most about. One with a lot fewer questions.

Now, have them stick it on the wall.

# Step Three: Pick Another

Now you take another item randomly and hold it up to that first one and ask, “Same, half as big, or twice as big?”

If it’s half as big, move it to the left. If it is twice as big, move it to the right. If it is the same, put it under the first one.

Keep doing this with each item.

As you do this, you’ll wind up moving lots of items as you go. At some point, you’ll find one that is half as big but twice as big as the existing ones. So you slide all of them to make room and create a new space.

By the time you’re done, you’ll have all the items that are roughly the same size stacked vertically, and each stack goes from smallest to largest horizontally.

# Step Four: Numbers

Until now, the items have been estimated only in relation to themselves, which is why this is fast. We haven’t tried to argue about what number is the right one or if the numbers are reasonable. Yet, somehow without that detail, we’ve captured the items in a small-to-big order. What is left is picking numbers.

I typically use time for numbers, but some people use story points. It doesn’t matter. Pick whatever is commonly used and understood.

Starting from the left, which is the smallest one, you’re going to ask the group to stop you when one item in that list fits the number. Think of it like trying on shoes. You’ll keep offering bigger shoe sizes until the team says it fits.

I typically do my time like this:

1. Hours
2. Day
3. Week
4. 2 Weeks
5. Month
6. 3 Months
7. 6 Months
8. Year

Quite often, once you get past the 3 or 6-month range, people will be entirely unsure if it’s a year or more or anything. That is fine. These are the monsters. You may also find that doubling stops working the further out you go. That is fine too. Pick the shoe that fits.

Once the team identifies the number that fits the smallest, take the next doubled one and check if it fits the next column. Keep going until you have an estimate over each column.

Remember, the estimate is for each item in that column, not for the entire column.

# Step Five: Debrief

This process up until now can take as little as 10 minutes. What you have are all of the items placed into estimate buckets.

People will have reservations about using these as hard estimates or commitments, and they should. The main thing you can use this for is to identify where things will go horribly wrong if nobody investigates. For example, if you’re doing annual planning and multiple things are hiding in the year column, you might be in trouble.

Also, this gives a quick way of seeing if things have any chance of fitting.

The bottom line here is to take away from this meeting the overall summary of the estimates and the risks and assumptions that the team raised as you estimated and debrief.

Those assumptions and risks are the work ahead.

# What About Inaccuracy?

I love this technique because of how obviously inaccurate it is.

In other words, this technique doesn’t pretend to give accurate estimates, so we can get on with answering the most important early questions of is it too much and what are the risks.

From there, work can be broken down more with more certainty as we go.

So next time you’re confronted with a huge estimation task, give this a whirl. In 10 minutes, you’ll have a good idea of what is about to happen and where the problems are ahead.

I have some free email series on dev career essentials and building high-performing teams. Find out more in my bio

image courtesy of Unsplash