Software Estimation

Table of Contents

Intro

Software estimation is a crucial aspect of project management, especially when dealing with complex work. As a developer and productivity enthusiast, I’ve encountered and shared numerous thoughts on this topic with coworkers and friends.

In this article, we’ll explore 11 laws of software estimation. At the end of each, you’ll find a thought experiment question for introspection and discussion in the comments, if you’d like to share your experiences.

1. The work still takes the same amount of time regardless of the accuracy of your estimate.

When I was young, my family and I would attend summer family reunions where we’d play tons of games – beach volleyball, horseshoes, kickball, bean bag toss, etc. Every year without fail, one of the most enjoyable past times was inspecting various sizes of glass mason jars and other transparent containers full of bright candies like m&ms, Swedish Fish, Mike & Ikes and Gobstoppers to guess how many were inside.

Every year I’d try a variety of approaches to guess the amount, but the point is, no matter how accurate or inaccurate my estimate, the number never changed.

Accurate estimation does not speed up the completion of the work. The actual effort required to complete a task remains the same. This is important to remember when considering the effort and cost of making the estimate, whether it takes place in a planning meeting or on a notepad on your desk. It’s rarely worth it to take the extra time to get a “more accurate” estimate, because in the end, the work will always take the same amount of time.

With the candy guessing game, the person with the closest guess won the jar of candy. In software task estimation, however, there is no prize for closer estimates. On the contrary, the quicker you make an estimate, the prize you get in return is a bit of your time back!

💭 Recall a project where your estimation was spot-on, yet the project still took longer than expected. What factors contributed to the delay? 🡇

2. No matter what you do, estimates can never be fully trusted.

Think of the last time you went to the grocery store. Depending on your level of spontaneity, you may have come home with any number of items that weren’t on your list.

I don’t trust myself to shop alone most days, especially when I’m hungry. Meandering through grocery store aisles can be unpredictable and complex. I never know what snacks will be appealing, which produce will be freshest, or how good sales will be on items I keep regularly stocked at home.

Software development is infinitely more complex than shopping. Estimates are inherently uncertain and subject to change due to unforeseen circumstances, making it impossible to trust them entirely. Since you never know what you’ll encounter, you can never be certain that your estimate is accurate.

💭 Share an instance when an estimate of yours proved to be completely off the mark, and discuss the lessons you learned from that experience. 🡇

3. Imposing estimates on others is a recipe for disaster.

Forcing estimates on team members can lead to unrealistic expectations, stress, and compromised quality of work.

We’ve all encountered the feeling of stubbornness that comes when you are pushed to do something, even if it was something you were already inclined to do. Somehow the act of someone else asking you for it makes it less desirable. In this case, it can even make the work take longer and ends up delaying the whole project.

Estimates should be used as a means of communication and collaboration among stakeholders to ensure that everyone has a common understanding of the project’s scope and goals.

💭 Describe a situation where you were pressured to accept an imposed request and the negative consequences that followed. 🡇

4. Estimates become more reliable closer to the completion of the project. This is also when they are the least useful.

This is one of the more obvious laws. When running a marathon, it’s challenging for even the most consistent of runners to predict their finish time with accuracy at the beginning of the race. Many factors can affect performance, such as weather conditions, physical and mental state, and the race course itself.

As you progress through the marathon and approach the finish line, your ability to estimate your completion time becomes more accurate. You have already overcome the majority of the uncertainties and can better assess how much time and energy you have left. However, at this point, the more accurate estimate has limited value, as you are almost done with the race, and there’s little room for significant adjustments to your pacing or strategy.

Similarly, in software estimation, the closer you get to the completion of a project, the more reliable your estimates become. The uncertainties that plagued the early stages of the project have mostly been resolved, giving you a clearer picture of the remaining tasks and effort required. However, just like in a marathon, these more accurate estimates are of limited use at this stage, as the project is nearing completion, and there’s little opportunity for significant changes or adjustments to the project plan.

In both scenarios, the key takeaway is that while accurate estimates are helpful, they are not always useful when they come late in the process. It is essential to focus on managing uncertainties, pacing oneself, and addressing challenges as they arise, rather than relying solely on estimates to guide the course of a project or a marathon.

Even so, be careful not to trip and fall! Even when you’re nearly done, you can still discover something that blows up the whole project. In software development, seemingly small issues can have massive consequences, so be careful and be flexible.

As a project progresses and uncertainties are resolved, estimates become more accurate. However, at this stage, accurate estimates may not provide significant benefits.

💭 Reflect on a project where your initial estimates became more reliable as the project neared completion, but didn't contribute much to the project's success. 🡇

5. The more you worry about your estimates, the more certain you can be you have bigger things you should be worrying about instead.

Obsessing over estimates often indicates that there are other, more pressing concerns that need attention. When your workflow is consistent and efficient, your estimates will be less important and it will be easier to focus on the work.

💭 Share an experience where your focus on estimates distracted you from addressing more critical issues in a project. 🡇

6. When you suck at building software, your estimates will suck. When you’re great at building software, your estimates will be mediocre.

Estimation accuracy is directly tied to one’s expertise in software development. Even experienced developers can struggle to make accurate estimates.

💭 Describe how your estimation skills have evolved alongside your software development skills.

7. The biggest value in estimating isn’t the estimate but to check if there is common understanding.

The primary purpose of estimation is to ensure that all stakeholders share a mutual understanding of project scope, goals, and resources. If this kind of communication is happening, your estimates are less important. Strive for clear communication and your team will be much better off for it.

💭 Share a time when the estimation process helped your team align their expectations and clarify project requirements. 🡇

8. Keeping things simple is the best way to increase the accuracy of estimates.

Simplifying tasks and breaking them into manageable pieces increases the likelihood of generating accurate estimates.

Melinda Mae - by Shel Silverstein

The best way to eat an elephant is one bite at a time. My team has a rule that no low level task can be estimated at over 8 points. If it is, it needs to be broken down into smaller tasks to break it up into smaller pieces. These can be divided between team members to ensure a lack of information silos, or can be assigned to a single developer who can focus better on each individual task’s requirements.

💭 Discuss a project where simplifying tasks and processes led to better estimation and improved project outcomes. 🡇

9. Building something increases the accuracy of estimates more than talking about building it.

Practical experience in building software provides valuable insights that improve estimation accuracy, more so than theoretical discussions.

Less talk - more action.

💭 Share an example of how hands-on experience with a project significantly improved your ability to estimate work accurately. 🡇

10. Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.

Overly detailed estimates can hinder project progress by consuming valuable time that could be spent on actual development.

💭 Reflect on a project where excessive focus on breaking tasks down into minute details delayed the overall progress and delivery of the project. 🡇

11. Punishing wrong estimates is often like punishing a kid for something they don’t and can’t know yet.

Punishing incorrect estimates is counterproductive, as the nature of software development involves uncertainties that even experienced developers cannot predict.

💭 Share an instance where you or a team member faced repercussions for an inaccurate estimate and discuss how it impacted the team's morale and productivity. 🡇

Conclusion

Software estimation is an essential yet challenging aspect of project management. By understanding these 11 laws, developers and project managers can better navigate the uncertainties of complex work, foster mutual understanding among stakeholders, and ensure successful project outcomes. Reflecting on personal experiences and lessons learned can help us improve our estimation skills and adapt to the ever-evolving world of software development.