Rules of Thumb for Software Development Estimations
Table of Contents
First, I planned on calling this article “Mastering the Art of Estimations: A Definitive Guide for Developers”, but then who am I to tell you how to estimate projects? I can only give you some pointers and describe some things that worked well for me over the years. So that’s exactly what I will do — give you some rules of thumb to make your life easier.
Ah, software estimation - the bane of many developers’ existence and the scourge of project managers everywhere. A constant battle of “tell me how much it’s going to take you” and “give me a clear description of the task first.” I'm here to bring some much-needed reality of the complexities of real-world development. I’ve had my share of estimations on both sides of the fence. I’ve seen it all. And I'm here to give you the harsh truths about software estimation, so buckle up.
And to you junior developers out there, pay close attention - this stuff will be the difference between a successful career and a lifetime of missed deadlines and frustrated coworkers.
Before we dive, a story from my personal experience. This was back in 2018 or 2019 when my business partner approached me and asked, “How much time do you think you need to build a mobile bank?”. At this point, I almost spilled my coffee, but I took a moment to gather my thoughts before I answered. “What do you mean a bank? I’ve never built a banking app. How should I know?” He said, “Well, just give me a ballpark based on your gut feeling; I need some timeline to sell it”. At this moment, I wanted to list him all the ways it could go wrong if we estimate based on such an absurd requirement. Still, I thought it might be a good challenge to see how good my gut feeling was.
I told him it would take me at least a year with a small team of 6-9 people. “Of course, we can refine the estimate as soon as you give me more details, but this should give you a timeline you can work with.” He said, “Okay.”
Eventually, we did build a mobile banking app — we spent several months on the initial designs, which were perpetually getting refined during the development phase. The app coding took ten months, a team of 7 people, and much scope-cutting to get to that first AppStore release. Even with the shortcuts we took (e.g., building with someone who already has a banking license instead of getting our own), we still barely made it, and we had a long list of features after that initial release that we needed to deliver.
So we can say my estimate was right, or better yet — the team made the initial product fit the estimate by cutting scope.
💡 So we can say my estimate was right, or better yet — the team made the initial product fit the estimate by cutting scope.
I’ve also been wrong with my estimates many, many times before. I remember grossly overestimating the development of some components for custom CMS. My team and I communicated that delivering the feature would take 3-4 weeks, but we were done in a week and a half. You’d think this is a good thing, and everybody was happy, but no, in the agency business, this makes the client believe that you’re inflating features to get more money, leading to you losing their trust in your expertise.
I also remember underestimating projects, which is quite dangerous if you’re an agency and doing fixed-price projects (which I try to do less and less). There was a project that I was pretty confident in implementing in the agreed time. Still, after we started digging, we found out the feature required us to do a major upgrade of some packages, which resulted in a cascading complexity in other places that needed fixes. It took us twice the time agreed upon to finish the project, but hey, we upgraded the underlying software, learned a good lesson, and made the client happy.
So let’s get down to the dirty business of estimations.
Why Do Estimations at All?
After reading my stories, you might wonder, "Why bother with estimations? Aren't they just a pain in the ass?" Sure, they can be. But estimations serve a crucial purpose in the realm of software development. Without them, no software project would be green-lighted. Even if it’s an R&D Project — someone at the top needs to see if the company can invest that much money and for how long, which requires some numeric value attached to a project. We'd be living in a chaotic world without estimates — with uncertainty, over-commitment, and missed deadlines.
Here are some reasons why we need estimations in the world of software development:
- Resource Allocation: Estimations help prevent under- or over-commitment of resources. You don't want to leave your team stranded in a sea of unfinished tasks, nor do you want them twiddling their thumbs because you thought it'd take six months to build a simple feature. Get your estimations right, and you'll have a well-oiled machine of a development team.
- Collaboration: Estimations create a shared understanding of the project size among team members and stakeholders. When everyone's on the same page about what needs to be done and when it's due, collaboration is more effective, and your team can focus on what they do best - writing kickass code.
- Sanity Check: Estimations help you, as an engineering manager or startup founder, to maintain a semblance of sanity in the face of constant deadlines and deliverables. By knowing how long tasks should take, you can make informed decisions about priorities, allocate resources effectively, and maybe even get some sleep at night. A proper Gantt chart of deliverables can alleviate stress on the weekend.
So we agree that Estimates are a necessary evil. Let’s explore the good, the bad, and the ugly, so you can learn from the mistakes of those who came before you and emerge a better, wiser developer. I hope.
Estimations in Software Projects
Estimations in software projects are about as sure as your favorite bar's closing time during a pandemic. We must acknowledge the inherent uncertainty and work to mitigate it. In my example of the banking app estimates - it’s a gut feeling imagining a team working on delivering and how I would go about building it, which modules first, which second, and what roadblocks I can imagine. Of course, you can’t account for thousands of unknowns, so the estimates should be on the safe side first and get shorter over time, not the other way around.
It’s much better to tell someone, “Okay, after a week of exploration, we can say that the timeline is 12 months instead of the initial 24 months suggested.” rather then "Ooops, the scope got huge and it's now 48 months instead of 24"
🚨 It’s much better to tell someone, “Okay, after a week of exploration, we can say that the timeline is 12 months instead of the initial 24 months that we estimated.” rather then "Ooops, the scope got much bigger and it's now 48 months instead of 24."
Here are some rules of thumb to follow when estimating in the real world:
No two projects are the same: Sure, there may be similarities, but there's always a twist that'll throw a wrench in your well-laid plans. The key is to learn from past experiences and apply that knowledge to future projects. If you’ve built a chat system before, it might give you some insights into the next one you need to implement. Have experience integrating the Stripe payment gateway? Well, you might transfer that experience onto the subsequent Braintree integration that is requested.
Uncertainty is your constant companion: Requirements change, stakeholders change their minds, and unforeseen challenges pop up like a bad case of acne. The best you can do is remain calm and adaptable and ensure your estimations have some buffer for the “human factor.” I usually add 20-25% on top of the estimates for things like people getting sick, third-party vendors being slow to respond, bureaucracy, and misunderstandings.
Communication is king: Many estimation issues stem from poor communication between developers, managers, and other stakeholders. Keep the lines of communication open and clear, and you'll save yourself a world of pain. Remember — it’s better to over-communicate than to expect people to communicate with you first. Need something from someone until a deadline? Annoy them with friendly reminders. Afraid someone would misunderstand your needs? Highlight and emphasize each requirement several times.
Most of these lessons came from my experience and missed deadlines, which is always an annoying event.
Wrong Ways to Do Estimations
It’s better to learn from the mistakes of others. Here are some misguided approaches to software estimation that you should avoid like a tequila shot on an empty stomach:
The blind guess: Plucking numbers out of thin air is a surefire way to disappoint everyone involved. Base your estimations on data, past experiences, and input from your team, not wishful thinking. We have this running joke in the company that every time someone comes to me and asks for an estimate, I always say six months, regardless of the project, which always triggers a follow-up discussion as that’s either too low or too long.
The "one size fits all" approach: Assuming that every task will take the same amount of time is a recipe for disaster. Different tasks have different complexities and require different skill sets. Consider these factors when estimating. Building an E-commerce shop does sound easy initially, and I’m sure you’ve built many before. But this task can take somewhere between a month and many years, depending on a huge list of factors of Inventory Management, Warehouse Integrations, ERP Integration, Ordering Flows, Marketing automation, etc.
💡 It’s essential to understand what the stakeholder means when they say, “I want a Shop,” as what you think and what they think can be very, very different things.
Ignoring external factors: Don't forget to account for meetings, code reviews, and other non-coding activities that will inevitably eat into your team's time. Failing to do so will leave you with overly optimistic estimations and a whole lot of explaining to do. I’ve known many developers who, when asked for an estimate, think of the raw coding time only. That. Is. Never. The. Case. Rule of thumb, 1.5x-2x your raw coding time estimation to get a good approximation of the real-time (incl. communication) you will spend on a task.
The fixed mindset: If you think your initial estimate is set in stone, you're setting yourself up for failure. Be open to revising your forecasts as new information becomes available and the project progresses. The cycle is as follows: 1. Work on the task happens 2. New information comes to light 3. Estimations are improved and communicated 4. Go back to 1.
Now that we've covered the usual pitfalls let's move on to the proper ways to estimate, so you can go forth and conquer the wild world of software development with confidence and panache.
Proper Ways to Estimate
With a clear understanding of what not to do, let's delve into some effective practices that help with software estimation.
However, my system does have one critical characteristic that I believe any effective estimation technique should have: it captures both time and uncertainty. An estimate that only includes time implies a high degree of certainty: if you tell me “that will take 10 days”, and we have a deadline 14 days out, I’ll assume we’re in great shape. If, on the other hand, we have that same deadline but you tell me “that will take 10-15 days”, now I know our deadline is at risk.A good estimation method that's based on uncertainty
Thus, the next step is to capture that uncertainty. Initially, you might think of capturing a best-case and worst-case scenario, but I don’t find that too useful. Instead, I prefer to capture expected-case and worst-case. Coming in early is never a problem, and in my experience, the best-case rarely happens. But it is important to capture how long something could take if things go poorly. Therefore, my uncertainty system starts with the expected time (captured above), and then applies an “if-things-go-wrong” multiplier:
These approaches are primarily subjective, but they helped me and hopefully will help you and your team navigate the uncertainties of development with confidence:
Break tasks down into manageable units: Large tasks can be overwhelming and difficult to estimate accurately. By breaking tasks into smaller, more manageable units, you can better assess the effort and time required for each component. You can imagine this as a recursive function: Input is the product you want to build. Can you build it in two weeks? No? Break it down into two components and call the same function on the two new components; if yes, return a Numeric value of two weeks, then sum up all the numeric values.
Use historical data and experience: Draw from your past experiences and projects to inform your estimations. Consider how long similar tasks have taken in the past, and use this information as a foundation for your estimates. There’s no way around it. As much as you learn from this article, you will have to overestimate/underestimate/fail a few dozen projects before you get enough experience.
Employ estimation techniques: Familiarize yourself with estimation techniques, such as Planning Poker or Wideband Delphi, which can help your team reach a consensus. If you have the time, especially in a big corporation, you can use those techniques to greatly increase the estimate accuracy. These techniques encourage collaboration and communication, ensuring everyone's input is considered. I mostly prefer planning poker for its efficiency and fast pace, but it’s a taste thing, and there are tens of different methods that you can look up on the internet. They rely on multiple people with different domain expertise to figure out how they would build it and then have a follow-up discussion with other experts.
Factor in uncertainty with ranged estimates: Instead of providing a single estimate, consider offering a range that reflects the degree of uncertainty involved in the task. This will help set realistic expectations and allow flexibility as the project evolves. Though sometimes people only hear the lower band, so you must explicitly mention that it’s a range and that “At least a year” does not mean “It will take us exactly a year.”
Seek out mentorship and guidance: Learn from more experienced developers (you’re already here, so good on you!) who have honed their estimation skills over time. Watch YouTube videos of how Spotify, Google, Meta, and Shopify built their stacks. Read case studies on how others have implemented modules that interest you. Read how Redis was built, find out how Databases are made, etc. These insights and advice can help you avoid common pitfalls. There are so many valuable things you can find on the internet.
Don’t get influenced by authority: If your estimate is five weeks but your manager/senior dev/someone else wants it to be 3 weeks — stick to your guns. Unless there are objective reasons to refine your estimate, there’s absolutely no good outcome if you give in to some persuasion to lower it.
Remember, no one is born a master estimator. Becoming proficient at predicting project timelines takes time, experience, and continuous learning. So, be patient with yourself and keep striving for improvement.
As we discussed above, estimates are constantly evolving numbers; if you’re lucky, they always go down. If you’re unlucky, they go up, but hopefully, they trend long-term downwards. Estimations are not made to be static; they need to be updated as the project progresses and new information becomes available.
Here's how to effectively take care of your estimates throughout the development process:
Track progress and compare to initial estimates: Regularly assess your team's progress and compare it to the initial estimations. This will help identify any discrepancies and allow you to address them promptly. Be honest and prompt if you think something is awry or not going as planned. There’s this excellent clip for Silicon Valley where Nobody Knows the Real Timeline , which you should try to avoid. See a problem — tell it now rather than later.
Revisit estimations during project milestones: As you reach significant milestones, take the opportunity to reevaluate your estimations. This can help you identify any changes in scope, new requirements, or other factors that may impact the project timeline. Milestones = Big things that usually get presented to the management, and the next portion of the budget gets approved. It’s a crucial time to voice concerns for the next phase so everyone is aware if there’s a delay. If you know that a third-party vendor will not finish the required integration until the deadline, it’s better to voice it and get an extra budget and/or timeline extension during the milestone meeting.
Communicate changes to stakeholders: If your estimations need to be adjusted, ensure all stakeholders are informed and on the same page. Transparent communication is vital in managing expectations and maintaining trust. I had a few cases where a developer did not communicate that he needed assistance and could not finish the task alone right until the deadline. They were pushing all their brain power to solve the job, and it was more important for them to solve the task ALONE rather than keep the overall project timeline intact. This is a no-go approach. If you feel overwhelmed and your estimates do not represent reality — communicate transparently and honestly.
The goal is to lead the overall project to a successful outcome and satisfied stakeholders.
Helping Your Manager Plan Better
At the end of the day, we're all in this together, and helping your manager plan more effectively is a crucial part of making your team's projects successful. You can think of your manager as a spider trying to process information from the different webs they have put in and making sure that none of them snap.
Here are some ways to assist your manager in their planning efforts:
- Be proactive in communication: I know I’ve said this a couple of times already, but I will repeat it. Don't wait for your manager to come to you for updates. Instead, take the initiative and share your progress, any potential roadblocks, and changes in estimates. This will help them stay informed and make better decisions long term.
- Share your expertise and insights: Your knowledge as a developer is invaluable in project planning. Share it. Help your manager understand the technical aspects of the project, and don’t get angry when they don’t know why your C++ compile error is blocking you from delivering on the timeline.
- Collaborate on risk management: If you have doubts — speak up. Work with your manager to identify potential risks and develop mitigation strategies. Think of worst-case scenarios, and prepare for them. This can help prevent surprises down the line and keep the project on track.
- Be flexible and adaptable. There is nothing to say here, but when your manager is doing the “Neo dodging the bullets” thing to keep the project on track, it would be decent to at least not be rigid and open to alternative ways.
I'm sure your manager will be thankful for the support and the team-spirit.
Work Culture Affects Estimations Accuracy
The environment you work in plays a significant role in how accurate your estimations can be. A supportive work culture that values collaboration, communication, and learning from mistakes will enable you and your team to provide better estimates.
If you’re already in a position where you can impact the culture at your company, here are a few examples that can make a difference:
- Encouragement to ask questions and clarify requirements: A positive work environment encourages team members to ask questions and seek clarification. Stupid questions are allowed, and even if you have to repeat the requirements a few times, it shouldn’t be seen as degrading to clarify ALL THE SMALL DETAILS.
- Emphasis on continuous improvement: A culture that values learning and improvement fosters an atmosphere where team members are motivated to refine their estimation skills over time. Failing is normal across many industries where experimentation is encouraged. You should normalize that and ensure people don’t fail twice with the same mistake — documenting the experiences and post-mortems.
- Openness to experimentation and adaptation: A flexible work culture that embraces change and is open to trying new techniques or methodologies can help the team discover more effective ways to estimate tasks and manage projects. Our industry is moving forward at a fast pace, and new tools, methodologies, and paradigms are being made public every year that make our lives better. Don’t be against change — embrace it. Evolve.
- Support for collaboration and teamwork: A work environment that promotes collaboration across all seniority levels can lead to more accurate estimates as team members share their expertise, helping each other improve. Even interns/junior developers should share their thoughts on the estimates — this allows them to learn from their seniors and try their hand at imagining how they would build this specific task. More experience = better estimates in the future.
Advice going forward
I hope that at this point, we all agree that accurate task estimation in software development is a critical skill that can significantly impact project success. As a software engineer, it's essential to recognize the nuances of real-world development and understand that it’s not always about the accuracy but more about some relative value that helps secure the budget and deliver a project in a limited time frame.
Here's some TL;DR; to help you navigate:
- Always be estimating.
- You’ll be wrong most of the time until you get good. And then you’ll still be wrong sometimes.
- Group estimates are more accurate than your single estimate.
- Embrace a growth mindset and be open to feedback and continuous improvement.
- Communicate effectively with your manager and collaborate with your team to ensure everyone is on the same page.
- Be adaptable and willing to experiment with new techniques and methodologies.
- Consider the impact of work culture on estimation accuracy and seek out environments that support your growth.
Remember, no one is perfect when it comes to task estimation. It's a skill that takes time and experience to develop. By remaining dedicated to your growth and learning, you'll become a valuable asset to your team and contribute to the success of your projects. So, keep at it, and never stop striving for excellence.
Enjoyed the read? Join a growing community of more than 2,000 (🤯) future CTOs.
Other Newsletter Issues:
Very interesting article. Thank you for sharing it .100% agreed from my 16 years of experience
Very verbose article with no concrete recipe, rule of thumb is as follows:
1) Generic estimate at first
2) Estimate refined by SA, Tech leads
3) Estimate further refined by Developers
Anyone who claims they can predict a new project on some “magic” principles, has no idea about IT development
Tossed decades of guidance out the window and ignored that the business projection and technical delivery estimate are two entirely different data points.
Projecting the cost and time of software delivery is far easier than all this.
Intrigued at see a Dilbert strip.
Apparently Adams isn’t flavour of the month but when one conflates the art with artist one deprives oneself of the treasures such as the Wagnerian operas.
In any case an excellent article which brought a few wry smiles.
I wanted to share ethat this looks like an interesting and quality article. Also, I’m personally strongly averse to the public persona of Scott Adams – so seeing his work deterred me from reading the article. I’m not asking you to make any changes, but I want to share my personal response. Best of luck.
Thank you for writing this article. I 100% agree with it.
It’s hard to believe but I dealt with a senior designer once who did not want to give estimates. I remember being surprised. It seems so obvious why estimate are needed that I did not know what to say. This article explains why estimate are needed, how to go about it, and how to improve and work as a team very well. I will definitely share this article with my pears, and ask software designers who don’t want to provide estimates, or are struggling with it, to read it.
From my experience, it’s because if they do so they would usually be asked to come up with a more ‘desirable’ estimate. After a few rounds of this, they would see the whole exercise as futile.
Management is always challenging on the estimation. Customer vs vendor.
What about quality? I can do the same job by spending 4 hours, writing a code that smells, without tests and possibility to extend the logic.Or I can spend 2 days, and simplify adding a new logic. Usually we dont take into account such cases.
Yes we don’t count on that. In estimation either one is problematic. Too high or too low. We can’t help but privide it as a range.
What if, you figure out what is the most important feature to build at the current time, and then ensemble/mob program the h*ll out of it, no estimates or planning needed, any reasonable deadlines will be met as you can not build it any faster.
Rinse and repeat, absolutely no need for estimates, and break it down into small enough chunks, you can project/predict when a certain feature, just as well as when you spend hours on estimating
Changing from Scrum to this with my team, doubled our output
* when a certain feature is finished
What do you mean by “you can predict when a certain feature is finished, just as well as when you spend hours on estimating”? How are you going to predict when a certain feature is finished, if you don’t estimate it? Or are you saying that you can’t properly estimate anyways and hence always have a bad prediction?
This is an awesome write up. Several very good points to reference when speaking with the business on estimates.
1. Figure out how much ideal engineering time it would take to do the task if everything is described accurately and there are no interruptions.
2. Multiply by 2 and shift to the next higher unit of measure, e.g., hours to days, days to weeks, weeks to months.
So if the result of step 1 is “4 hours”, then the final answer is “8 days”.
So basically, if the estimation is 1 year, I should call it 2 decades, right? 😂
This is perhaps one if the very few articles I enjoyed reading.
Software estimation is just wrong. It doesn’t matter how good you try to estimate. You’ll never be right.
Do not estimate, do projection instead.
I understand the industry expect a number and a budget. But this is just brought in software development from other fields. It simply doesn’t apply in software development and we need to change the way we approach it.
If us, developers, do not understand this we have no chance project managers and business will ever get it.
Estimation, the ones with some value, are possible only when every detail of what you have to do has already been analyzed. And by the point you do that kind of analysis you might as well implement the feature instead.
Imagine a world where we are not talking about applications, programming… But instead we are dealing with engineering. Only estimation needed is the time to create the technical documentation. Enginnering happens on paper. Make clients pay for the technical documentation. Having good documentation makes development quite predictable. All this agile, Jira, task, story BS is making us engineers look like idiots. Imagine building a skyscraper and using BS technics/tools we are using in software development…
Nice Sim City 2K reference in there
Never give an estimate before you are delivered full agreed upon requirements by business and IT.
I always multiply software estimates by pi, and I’m usually pretty close!
The actual needed time is two times the estimate. Using pi as a multiplier gives from for extras, lazy days, setbacks and keep you still within the plan.
Reminds me of the 80/20 rule, or so it seems to apply in my life with software development: the last 20% of a project takes 80% of my time. Am I saying that right? -_- Anyhow, I find that if I time my original estimate by 3x, all is well.
I enjoyed your article. Thanks.
Excellent approach! Thanks a lot for sharing!
You should know that “Rules of Thumb” is not a good idiom to use due to its origin. Men were allowed to beat their wives as long as the stick was no thicker than the size of their thumb.
Oh, yes. That is true indeed.
Just because it was mentioned in a movie doesn’t make it true. There is no evidence to support this claim; in fact, English common law did not allow wife-beating at all.
You should know that that is wrong.
this statement is erroneous https://en.wiktionary.org/wiki/rule_of_thumb the etymology is from 1658 using the thumb as an imprecise measurement for a “ynche” (today know as “inch”). https://www.theguardian.com/notesandqueries/query/0,,-7903,00.html
Comments like this are why software engineering is a male dominant field.
In my country we call it a “rule of fist”. Take that how you you will.
Another thing, worth to be mentioned, is that the initial estimates are more like a focus point, that is used to synchronize the project processes. If you can’t meet the hard deadline, it’s usually acceptable to sacrifice some optional features, but not to compromise the quality of the main use-cases, while for the other cases the deadline is flexible, but the feature-rich product is must have.
Thanks, this is very insightful
“Plans are worthless, but planning is everything.” –Eisenhower
I’m a CRO and for that last 20 years I’ve taken any estimate given to me by Dev for new products and/or new features to existing products and 3Xed that estimate. It’s usually very close to actual release date and keeps customers and salespeople happy. There are simply too many unknowns for Dev to contend with and they are also essentially “forced” to provide unrealistic delivery dates to accommodate a business plan or a capital raise. If one major unknown pops up, or one key developer leaves, or there is a “fire” on different product that requires attention, the project will experience major delays. – My 2 cents.
Though, how do you manage the business side of the house after telling them it will actually take 3x longer? If biz doesn’t accept the longer timeline, the environment will become miserable.
Integrate your business partners into your project. They should attend your weekly meetings such as project progress, bug fix priorities, requirement trade off discussions…
Read “The Mythical Man-Month,” by Frederick Brooks
My rule of thumb is to always 1.5x or 2x my estimates depending on the size of project. For smaller projects I like to double. And for bigger projects I’ll usually do 1.5x to account for unknown unknowns. Also don’t forget to take into account your teams vacations during the length of the project.
Yes, this is an excellent article👍 However how would the details in the article apply to only a Programing Team of ME, MYSELF, & I.❓ I’ll do some more cogitating w the article to see what factors could be used for my PROGRAMMIMG TEAM, of ME, MYSELF, & I. Thank You for writing this Technical Article. It’s in my ‘POCKET’
Just a tester
Wonderful article and thoughts. These strategies will help me to better scope out tasks with my team. Thank you!
Thank you for showing the justification and ideation of micromanagers. Click and fire.
Excellent article. Estimation and specially size estimates are always missing in software projects.
Like your visuals and overall breakdown.the highlighted words, maybe put more visuals on their importance instead of highlighting :notes make it clear need to know more and I most certainly do.
I was once in a meeting with a customer who was unhappy part of the project was behind (a highly complex subsystem with vague requirements being understood on the fly), a senior architect consultant they brought in to analyze why we were late and our leadership team. After going over the project status and designs in great detail he looked at them and was like “what’s your beef? They are doing all the right things and building great stuff.” They said “but they are over schedule”. The guy rolled his eyes and said “look, you basically asked them how long it would take to come up with a clever idea to solve a problem no one has done before! They said x weeks and it took y weeks cause their guess was off and they found z problems that were unknown at the time. That happens with GUESSES!”
They left us alone and let us get on with it after that.