Victor and Code

The first time you finish a piece of software you've estimated, you discover a harsh reality ... software estimates are hard. Unexpected edge-cases, dependencies, meetings, and a thousand other things. This law summarizes it perfectly:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

My objective with this post is to provide you with a framework to help you understand and create better software estimates, which will allow you to reduce risk in your projects and align expectations with other stakeholders.

What is a software estimate 🤷

A software estimate predicts how much effort is necessary to create, modify, or maintain software. You give estimates in some unit, which in my experience is usually man-hours and story points.

An estimate does NOT imply a commitment. It represents the most well-informed guess you can make with the given restrictions of time and knowledge. This difference is often overlooked and can be the source of conflict and frustration. This doesn't mean you should not commit; it means you should treat estimation and commitment separately. As a professional, you should make a commitment when needed after carefully evaluating the situation, and preparing an estimate. But, you should also say NO when pressured to commit to work that isn't adequately estimated.

Who needs estimates and why 📅

It is crucial to understand how estimates fit into the bigger picture of your organization 💸. Estimates represent cost, which helps inform different stakeholders' decisions. Here are some common scenarios:

• Calculate the price of a project: Consultancy firms and freelancers use estimates to calculate how much they charge clients. For this reason, it is of critical importance that estimates are accurate.
• Defining product roadmaps: Product teams need to know how long a piece of software will take to shape their plans and help coordination.
• Sprint capacity planning: For teams working in sprints, estimates help scope a sprint and reach a sensible commitment.

What makes estimating so hard 😟

There are many reasons why doing estimates is so hard. This list presents what I believe are some of the most important ones you should take into account.

Communication is hard

To develop software, you need to have conversations between people who are analyzing the problem and people who will design and create the software. During these conversations, information can be wrong, misunderstandings can happen, or data might lack documentation. It can take one big misunderstanding for an estimate to be dozens or hundreds of hours wrong.

Every software is different

It's almost impossible for a software that is more than a couple of code lines to be completely the same. They might be solving very similar needs (e.g., shopping cart), but they have been created by different people who chose other technologies at a different point in time, for a given market, with specific time constraints. All these decisions can drastically alter how much effort is needed.

Scope creep

Scope creep refers to unexpected changes that increase the scope initially planned for the project. It is natural that in a software project, you stumble upon an unexpected. Expect some changes to be asked, but mind that small things can pile up, so make sure that these changes are: discussed, negotiated, documented, and postponed (if possible).

Variations in experience and availability from the development team

Some team members might lack experience with the technologies used in the project; this is not rare considering how technology advances. It's also possible that you don't know all these technologies in advance, which implies some learning time and occasional head bumps.

The team's availability might also be unknown in advance. It would be best if you planned for holidays in advance to adjust the estimates. Unfortunately, things like resignations, lay-offs, and personal problems can happen without any warning.

The team's experience

The team's experience can make all the difference between a good and a wrong estimate.

• Technical expertise: An expert is more likely to know the patterns that will help implement the solution faster and will also be able to identify the risks more easily.
• Experience working together: People that have experience working together develop habits and processes that make them more productive.

Who should do the estimate

Ideally, the people doing the work should be doing the estimation. After all, they are the experts. If this is not possible, try to find someone with experience in similar projects and ask how much it took for them and what problems they found along the way.

Tools and tips to improve your estimates 🧭

These recommendations aren't set in stone, so I encourage you to adapt them to your team.

Have the right mindset

Acknowledge that software estimates are HARD (ask any software engineer ever). Even with all the information in the world, you are very likely to be wrong. However, also keep in mind that estimations do get better with experience. As an engineer, help other stakeholders understand this.

Clarify if you are doing a high-level estimate or a low-level one

Knowing if you're doing a high-level or a low-level estimate will help select an estimation unit and guide how much time you spend going into details.

Split the work

Split it into smaller parts, especially when estimating big loads of work. This separation can be epics, features, screens, use-cases, user stories, or whatever you find comfortable. Even when estimating at a user-story level, you might later find that one of them is too big, so you can just split it.

Choose the right unit of estimation and make sure everyone understands it

I like Uncle Bob's advice around how estimates should never be a date but rather a date range. The cool thing is that you don't have to be working with dates to follow this advice. Whatever type of estimation you are doing, it's more accurate to give a range with the following values: best case scenario, some drawbacks (but nothing major), and worst-case.

Also, all people involved in the estimate should understand the unit of effort you'll be using. For example, if you're using story points, have an example of what a 1 or 3 points feature looks like. If you're using time, explain if you expect this to be "work-hours" or "productive non-interrupted hours."

For high-level estimates, I've found T-Shirt size estimation the easiest to use. You can also estimate in weeks or months.

For low-level estimates, story points are a very wide-spread unit to use because they already take into account uncertainty and risk. You can also use man-hours but be explicit about how you will handle uncertainty and risk; you can add a percentage or a formula based on your past results and other variables. When estimating significant efforts, increase the amount of risk since things like integration, communication, and dependency issues are more likely to happen.

Gather all possible information

This step varies from high-level to low-level estimates. With high-level estimates, you probably won't go much into detail and identify the main components/tasks of the project. For low-level estimates, you'll want to understand things like assumptions, inputs, outputs, UI design, non-functional requirements, dependencies, happy-paths, and edge-cases. Having your own definition of ready is useful here.

Make sure you ask questions and clarify when needed.

I can't stress this enough don't rush it. Software estimation is an essential step in the software development life cycle, and it has a massive impact on stakeholders' expectations. On the other hand, don't take forever, the lower level you go into an estimate, the higher the cost.

Defer estimation if more information is needed

If you have a big unknown and need to do a bit of research, do it before providing an estimate. If you definitely can't wait, give the estimate but underline that you have some assumptions about that estimate.

Give your estimate

Now that you have selected a unit of effort, you have split your workload, and you have researched the necessary information; you only need to start assigning numbers. I have found better results using a consensus-based technique like planning poker rather than having a single person like a tech lead estimate on its own. The former allows more people to identify edge-cases, bring their experience, and have more ownership of the final number.

What to do if you know you are going to miss an estimate 😤

After what I've presented here, it's clear that estimates often fail. So we should be prepared for such cases. First and foremost, if you know your estimate will be missed, have a precise analysis of how behind-schedule you are, the reasons for the delay, accompanied by a proposal of how it can be amended or at least minimized.

Then, proceed to deliver the bad news so you can adjust your plans and ask for help. Be clear explaining the reasons and avoid compromising the software's quality since that will be more costly in the long-run.

Finally, do not fall prey to the man-month myth where you think people and effort are interchangeable. Adding new people to a delayed project almost always causes it to slow even further because of communication and training.

Final thoughts

Thank you for reading this far. I hope this article has provided you with useful information to improve your estimates and reach your organization's or personal goals. Don't forget to share the article with your team! 🗣️