The Beginner's Guide to Software Estimation

I remember the first time I was asked to give an estimate.

It caught me by surprise.

I was brought into a room with my boss, boss's boss, and my boss's boss's boss, and we all sat at a round table looking at each other.

A couple of analysts starting reading some requirements from a client. A brief discussion was had around them.

Then, my boss turned to me and said "how long will that take?"

I didn't know what to say. Nobody had prepped me for this. I wasn't told I was coming into this meeting to provide estimates. I thought I was there to learn.

Everybody around the table was staring directly at me. I was fumbling.

I looked at a piece of scratch paper in front of me and started writing some numbers down. I didn't know what they were for, definitely not for this estimate.

After what felt like an hour, but was realistically probably a full minute, I decided to just say the first thing that popped into my head, "I don't know, 600 hours?"

My boss laughed then told the table to put it down at around 1200 hours.

This was not my favorite day.

Obviously I had a lot to learn, but one question just stuck with me. How do you estimate the amount of work that needs to be done?

The Purpose of Estimates

The first thing you should know before you start estimating is what they are used for. You throw out a number to your boss/upline, then what happens?

Your estimate is going to be used primarily for two things:

• Planning
• Billing the Client

Planning

The senior managers, directors, and VPs of your company are concerned with getting work done. They need to know what work will be done by what time. So they need estimates on how long projects will take.

They know how much capacity each development team can handle per month/quarter/year. So they will schedule dev projects to fill that capacity. The estimate you provide will help with that capacity planning.

Let's say your development team has 3 people on it. Each person works 40 hours a week, about 160 hours a month, so about 480 hours in a quarter. With the three of you, that's roughly 1500 hours of work you potentially could get done.

Imagine there are 5 projects that need to get done by your team. These projects have estimates of 800, 400, 300, 200, and 50 hours each. By capacity planning, you know that not all of the projects can be done by the end of the quarter. Managers will schedule up to a certain percentage of your capacity to allow for risk in case development takes longer than it should.

So in our example, given the estimates provided, we know we can commit to getting the 800, 400, and 50 hour project done, while still allowing ourselves some wiggle room.

Billing the Client

Software companies are businesses, their objective is to make money. If a client wants a custom project done for them and are willing to pay for it, your estimate will help determine that cost.

They give the requirements to you, you say how long it will take to build, sales will convert your estimate into a dollar amount and send it back to the client. Then it's up to them to decide if what they want is worth the cost.

NOTE - This is not applicable to every software company. Not all companies do custom development. If your company does not do custom development, then your estimates are primarily going to be used for planning.

Key Factors in Estimating

Now that you know why you are estimating in the first place, it's time we figure out how to estimate. Keep these 5 key factors in mind the next time somebody asks you how long something will take to build.

Photo by AbsolutVision on Unsplash

Don't Estimate How Long It Will Take YOU

For the first two years of my "estimation career" I always was stuck in the mindset of providing an estimate of how long it will take me to build something. But that is not what is being asked.

You must remember that the estimate you are giving is for a development team. Don't assume the people doing the work know the domain exactly like you do. Add a little buffer for people to learn the codebase and domain.

A good trick is to assume the most junior person on your team is going to be doing the work.

Go High, Not Low

Remember, the primary reason we are giving estimates in the first place is for planning purposes. So you do not want to provide an estimate that you think you could potentially go over.

If you go over your estimate, then you're getting into unexpected overages, which throws off the schedule.

It's ok to be 20% off in your estimate, but you want to make sure that 20% was an overestimation, not an underestimation.

Whatever you think it will take -- add 20% to it. It is always harder than you think!

Is Upskilling Required?

Does this project require the team to learn something new? Maybe you're typically a thick-client application developer, but this project is to build a web page.

If there are components that require developing new skills (aka upskilling), take that into consideration of your estimate. Give your team the opportunity to discover the ins and outs of new patterns/languages/frameworks in your estimate. It has to be done, so you should account for it.

Photo by Matheus Frade on Unsplash

Do You Have Examples?

The easiest types of estimates are the ones that build on patterns you already have in place.

If the development team has reference material in the form of already built software, your estimate can drop significantly. Developers like the whole "copy/paste/replace" model of development, and honestly - so does the schedule.

Always think if this has been done before at your company. Are there experts that have done this type of thing? Use them for a consult in the estimate, and definitely use their code as a reference when you go to build it.

Remember the Analysts

Oftentimes you will be asked to provide a complete estimate. A complete estimate includes developer, business analyst, and quality assurance analyst time.

Providing a number just for dev time won't cut it. You have to account for BA's to write documentation, draft user stories, and run sprint reviews.

You also have to take into consideration the time it will take a QA to get through testing. Maybe you have some automation that needs to get built around this project as well? All of that takes time, and it should be included in the estimate.

Conclusion

Becoming comfortable with estimates takes time. It's a skill. With any skill, you need to practice.

Over time, providing estimates will become more and more natural. You'll remember the gotchas, understand how long things take to build, and pull from your experiences.

If you take anything away from this remember two things: it's always harder than you think and it's better to overestimate than to underestimate.

Nobody will be mad if you come in under the plan. In fact, they should be delighted! You now have more time than expected to take on other projects.

So size big, and remember that the estimate is just that -- an estimate.