Thread by @svpino

If you want to make money 💵 as a Software Developer, you need to get good at estimating work.

A good estimate is the foundation for a profitable project. (There's more needed, but good estimates are a great start.)

This 🧵will help you understand estimates.

⬇️

Before putting an estimate together, you need to understand what the heck you are building.

This doesn't mean that you need every single detail (quite the opposite,) but you need the overall picture.

Let's talk about 3 overall things to keep in mind:

👇

▫️ Don't give off-the-cuff estimates before having the full picture in mind.

▫️ Take your time and break the project down into smaller, actionable steps.

▫️ Capture enough details about the necessary functionality but don't be too specific.

👇

Some people would argue that you need to be as specific as possible. In my experience, this usually backfires:

1. It's hard to capture all of those details upfront.

2. Getting too specific will limit your ability to negotiate.

You want to capture "WHAT" instead of "HOW".

👇

First, let's gather our requirements:

1. Identify the most important features to finish the work

2. Identify hidden features (things that need to happen but aren't usually called out)

3. Now cut off any non-essential features

👇

4. Now cut off anything that's overly expensive (either in time or budget)

5. Identify dependencies (with other teams, the client, etc.)

6. Identify any potential risks to meet timeline or budget

7. Finalize your list adding enough details to discuss with the client

👇

Now that you have the requirements, is time to estimate the work:

1. Ensure you have enough details of each feature before estimating it

2. The person that will build a feature should be the one estimating it (if possible — can't happen all the time)

👇

3. Your estimate should include every type of work to deliver the feature (development, QA, deployment, etc.)

4. Ensure your requirements have similar granularity. Avoid having week-long requirements mixed together with hour-long requirements.

👇

5. Either use 2-point estimates (MostLikely - Pessimistic) or 3-point (Optimistic - MostLikely - Pessimistic)

6. Document every assumption you make to hit those estimates

7. Avoid estimating in time when possible. Use a proxy metric (like Ideal Days or Story Points)

👇

To compute the final estimate, I like to use the PERT approach (Google it):

(Optimistic + 4 * Most Likely + Pessimistic) / 6

This will give you a weighted average of your estimation. Beats "add 20% to the final number."

(There is a bunch of other stuff you can do here.)

👇

Here is a checklist to go through and ensure you don't forget anything:

1. Include time for documenting and analyzing requirements

2. Include time to discuss the scope with the client

3. Include time to plan the release of the product

👇

4. Are there any third-party integrations that you need to estimate for?

5. Do you need time to think about performance, scalability, and security?

6. Do you need time to handle the dependencies you identified?

7. Include time to deploy. More than once

👇

8. Include time to transition the project to the client

9. Do you need to train the client or their users?

10. Are there any expenses that you should include as part of your estimate (like tools, libraries, etc.)?

11. Should you provide a warranty?

👇

With all of this, you are now ready to send a proposal:

1. Pick how much you are going to charge (usually your weighted estimate.) You can also go with a range.

2. Decide the timeline (how long will it take?)

3. Do not intentionally underestimate to win the project!

👇

Consider the effect of the Cone of Uncertainty (Google this) on the accuracy of your estimate.

Your estimate cannot have more accuracy than is possible at your project's current position within the Cone.

But, what happens if your estimate comes out too high?

👇

1. Remember your estimates are already very optimistic! Don't reduce them without writing down assumptions.

2. Use multiple estimation techniques, and look for convergence or spread among the results

3. Reduce scope

👇

4. Spend more time on those features with the higher estimates (or the larger spread in their range.)

5. Propose simpler solutions to some of the features

Always remember that if you torture the data long enough, it will confess to anything. Don't push it!

👇

Finally, present the client with the following:

1. List of features included
2. List of features out of scope
3. Dependencies
4. Risks and unknowns
5. Timeline
6. Budget
7. Confidence on the estimate

Make it pretty.

👇

Finally, I understand that there are multiple ways to sell work that don't need fixed-price estimates. But they aren't realistic in every scenario for every person out there.

Parting words: Fix your budget, but always keep scope flexible!