Brandon Eleuterio

Articles

How to Estimate a Software Project

Mad Hatter Tea Party
Image by azzy_roth from Pixabay

Summary

Background

Estimating software is difficult. Much like a tea party with the Mad Hatter, it always seems to take longer than you think. How do you combat this problem? The two most popular strategies are:

With either of these choices, you’ll almost always be wrong and stressed about your poor estimation skills.

It’s not your fault. You’re following the advice of most software builders. Fear not. There is a better way.

Rough Drawing

Properly estimating a software project starts with a picture. Follow Basecamp’s lead and create a fat-marker sketch of what you want to build.

Fat Marker Drawing

This does two things. It puts on paper the picture you have in your mind and it describes your plan, without too much detail, in a way that words can’t.

Fat Marker is a style of drawing that forces you to stay high-level. It’s impossible to get detailed with fat markers. The point of this exercise is to create a visual outline of what you will build so that you and others clearly understand where you plan to go.

You’re welcome to use actual fat markers and paper. The tool I prefer for creating virtual fat-marker drawings is Sketchboard. It has collaboration features well-suited for a remote work environment and drawing tools that are impressively imprecise.

Backcast

Drink Me
Image by Clker-Free-Vector-Images from Pixabay

Imagine you have deployed a map feature to a customer and they love it. What steps did you take to get there? Did you tackle the difficult high-risk tasks first? Did you create unit tests along the way? Did you discover a novel approach to searching? Again, stay high-level. You’re not trying to solve the problem yet.

Backcasting is a strategy used by World Champion poker player, Annie Duke. In her book Thinking in Bets, she describes backcasting as working backward from a successful outcome to better understand how you arrived.

Premortem

Tall Alice
Image by Clker-Free-Vector-Images from Pixabay

You may have done a postmortem in which you look back from a negative outcome retracing your steps to discover where things went wrong. Also employed by Annie Duke, a premortem is similar to a postmortem except the outcome has not yet occurred.

Imagine you have deployed a map feature to a customer and it fails. Zooming doesn’t work, the graphics are grainy, and search is inaccurate. The customer is grumpy! What mistakes did you make and how could you have avoided them? How likely are mistakes like these? Did you feel rushed? Again, work backward to discover the steps that led to failure.

Add it Up

Paint the Roses
Image by Clker-Free-Vector-Images from Pixabay

Now that you’ve gone through these exercises, write down a description of your solution from a high level. Pretend you’re describing the project to a non-technical business person. Describe how your solution addresses a customer or business need.

How long will this take? Before you proclaim, “2 weeks!” and start hammering away, take a moment to think. Does your estimate include solving the key problem? Is this the gold-plated solution or the bare-bones solution? You want your proposed solution to be somewhere in between gold plated and bare-bones to allow for wiggle room. Have you taken into account high-risk challenges that could lead to failure? Are there no-fly zones you should explicitly avoid, either because they would take too long or would be too risky? For example, implementing search can be complex. Mark it as no-fly and save it for another day.

Consider the size. If this will take 2 months or more, consider taking on a thinner slice. If this will take less than a week, are there aspects you’re overlooking? Basecamp likes 6-week projects. With practice, you’ll find your own sweet spot. The key is to work long enough to enable meaningful work without getting lost down a rabbit hole. Remember, projects are risky. Until customers give you feedback, you’re making a guess. The longer you spend on a guess, the more expensive it is to throw it away.

Time is Fixed, Work is Fluid

Time is Fixed
Image by OpenClipart-Vectors from Pixabay

Imagine work has begun. You’re halfway through and realize you’ll likely blow past your deadline. What should you do?

A. Ignore the deadline

B. Trim tasks from your project

C. Pull one or two all-nighters

D. Recruit outside help

Answer: B. (Hint: always guess “B”)

Basecamp champions this idea of a fixed deadline and a flexible scope. The principle here is minimalism. A fixed deadline forces you to cut the extraneous and unnecessary parts of your project. When your project is complete, you want clear and precise feedback from the customer. Finished products clouded by fluff tend to elicit murky reactions. Be precise with your solution.

Up Next

Effectively prioritizing chunks of work so the high-risk foundational tasks are tackled early on, allows cutting partway through a project without losing the essential work. I’ll dive into prioritization strategies in a future post. Stay tuned!

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top