How to Estimate Software | Guide for Non-technical Folks

How to Estimate Software | Guide for Non-technical Folks

The first thing a startup founder wants to know when starting to build a product is how long will the project take to implement and how much will it cost.

This post aims to provide steps on how to estimate software projects. To estimate a software project, you need to know that estimates are not promises, but educated guesses, understand why developers underestimate, learn different estimation methods and focus only on must have features.

Why is it important to accurately estimate?

In this blog I will specifically look at estimation of MVPs (Minimum Viable Products).

Why knowing how to accurately estimate is important? Most first-time entrepreneurs either grossly underestimate or overestimate development efforts.

The main goal of the software project estimation is not to predict the result of a project but to find out if the project realistically can be built within the estimated timeframe given the resources you have.

In one of my recent posts, I reviewed how much will it cost to build applications like Uber, Evernote, and WhatsApp. While numbers vary significantly from one country to another, or from one development company to another, one thing is still true in all cases: the cost of building Uber app is twice higher than the cost of Evernote.

Estimating software projects is not a simple task, knowing how long it will take to build an MVP will help to avoid unrealistic expectations, overspending, failed projects. The only purpose of this site is to help startup founders to reduce the probability of failure when they team up with outsourcing partners to work on the Next Big Thing.

But here is a problem: Development companies more likely fail to meet deadlines than they exceed expectations. Another concern I hear a lot is how non-technical people not sure that the developers are not overcharging for their services. Nobody wants to pay more, and nobody should.

I decided to give you some practical tips that can be useful when you are making a software project estimation, so you can make an informed decision on whether the idea is worth pursuing or not.

The approach I am about to suggest applies to both projects build in-house and with help of outsourcing companies.

Reasons why software project estimates are almost always wrong

If you ask any outsourcing company what the main reason is why can’t they give accurate estimates, they would reply that it usually is a customer’s problem.

Each time they receive a request to quote estimates outsourcing providers usually provide a very general estimate based on their experience with similar projects and the historical data (if they track estimates vs real development time).

The reason for such an approach is because most customers provide very generic project description of what a product is supposed to do. When the requirements are vague then it is almost impossible to give accurate estimates.

Fortunately, the opposite is also true: more detailed requirements result in more accurate estimations.

To illustrate how hard it is to estimate a software project let’s consider planning a one day drive from Washington, DC to Jacksonville, Florida. According to Google Maps if I leave DC at 7:00 am on April 10 I will be there around 6:40 pm.

But even Google which measured millions of journeys for years is careful enough to provide me a time of travel within a range from 9 hours 40 minutes to 11 hours 40 minutes. I drove once this very distance and I was in Jacksonville after 2 am next night – it took me 17 hours to finish so Google was way off.

The issue with software estimation is even larger because almost every single project is custom work. There is no one path from point A to point B in development, and if Google with lots of data fails accurately estimate the trip that was done by multiple cars imaging how hard is to estimate a custom project where most of the parts are built from scratch.

If this was not enough there are fundamental issues with developers’ estimations.

5 reasons why programmers always underestimate (and 1 reason why they overestimate)

1. Ego

I met a lot of good and bad developers and I found one interesting thing that is common for most developers (both bad and good). Most programmers think that they are smarter than most of the people.

Every time when a non-technical person asks a developer a question the developer thinks that the client is a complete idiot. Programmers do not understand why customers complain that they cannot log in to the system while CAPS lock is on (I know it was a lame joke).

2. You and programmer mean different things

When you ask a programmer how long it will take to build a report he may answer that it would be done in 3 days. When you come after 3 days the report most likely would only be halfway there. There are 2 reasons for this.

First, when a programmer gives a 3-day estimate he or she means 24 hours assuming that the work is done in a perfect environment – without interruptions (explained in next point).

The second reason is programmers estimate only the time to code. What they mean is that the work will be done in 3 days if the code works correctly as written which is never a case. Any good programmer spends at least 50% of one’s time on debugging and testing.

3. Interruptions

Every time you ask a developer “How is it going?” he or she loses a context and it may take 15-20 minutes switch back to work. Sometimes, when I am deep in debugging something, I may even ignore anyone who tries to talk to me. If it takes me 20 minutes to reach a breakpoint in the code, I am debugging you have to have a very serious reason to interrupt me.

Everyone I know doesn’t like meetings, but developers hate them most. Most developers view meetings as a huge waste of time. In one of the companies, we decided to schedule meetings in one day because there was only one day when everyone was in the office so Tuesday was a day when nobody would write a single line.

If there 4 hour-long meetings with 1 hour between each of them no one will even try to do something knowing that they won’t be able to finish anything before the next meeting.

And since meetings are usually never allocated in sprints managers keep wondering why development is slow.

Sometimes, a task can create new tasks for the same project. Those new tasks will never be added to the initial estimate, but they still have to be done and managers again wonder why the development is slow.

Your responsibility as a Product owner (or manager) to remove any blocking issues – issues that do not allow a programmer to continue the work. Examples could be missing API documentation or testing environment.

4. Estimates are non-transferable

If it is possible to make sure that the person estimating the development effort is a person who will work on the item. Every developer has a different style and different speed so it is hard for me to assume how long will take for someone else to complete the task. I can estimate how long will it take me, but never for someone else.

5. Estimates made for unfamiliar technologies

One thing that most developers like is playing with new technologies. Often, if there are two possible solutions: one with old technology and another with the new – developers vote to work with the new one. They may even tell you how much time would be saved with the new technology. But any new is technology a substantial risk which generally should be avoided.

When I first learned about API Management service in Microsoft Azure I gave a task to the developer to use it to protect our API. The developer spent a month and he failed to implement the solution because the service was just released and didn’t work properly for our needs. Bottom line, we lost a month of dev time and had to build another solution.

6. Overestimations

Overestimation is the other side of the spectrum of incorrect predictions. In my experience, developers usually overestimate when they are afraid to fail to deliver on time. It happens if developers were already burned when software was delivered late or when they are not confident in their skills.

Other times that must be considered

So far, we were examining development efforts strictly related to the process of building MVP.

However, there is other supporting work that is often gets overlooked, such as testing, requirement analysis, meetings, deployment, design, and others. Sometimes developers can perform some of these activities, but in other cases, you will need QA, UI/UX designers, DevOps engineers, and Project Managers.

If the MVP is only needed to get money from VCs or to prove the concept on a high level you may not need to worry about next problems:

  • Scalability
  • Performance
  • High availability
  • Security
  • Maintainability

While everything in the list above is must have in the final product, I wouldn’t waste too much time and money on optimizing MVP. Many startups end up pivoting from the original idea so time spent on improving the scalability of the solution which may change significantly is a lost opportunity.

So, now when we know that estimates are never accurate what should we do with this information?

The first thing we have to realize is that estimates are not commitments. They are not the promises that developers keep breaking. Estimates are guesses, sometimes guesses are good, sometimes not so good.

What estimates provide, however, is a high-level sense how big the project is and generally can tell that Uber app is more complicated and requires more time and resources than Evernote app.

Also, remember that estimates for bigger projects are less accurate than estimates for smaller ones. Using Google Maps analogy, it is easier to predict the travel time from Baltimore to DC than from DC to Jacksonville.

If it is impossible to get an accurate estimate, then the next question is there a way to reduce the discrepancy between the time we think required for the project and actual time?

The answer is yes. There are several various methodologies aimed to improve the accuracy of our guesses.

Dīvide et Imperā

The old maxim Divide and Conquer applies to many things in our lives and unsurprisingly it fits in our case as well.

While it is hard to access a big problem, it is always possible to split it to smaller chunks and access smaller ones.

This approach is called a bottom-up approach. The team breaks down a project, estimates each individual task, adds them together and gets a result in man-hours which in turn provide the cost of the project (man-hours multiplied by the cost per man hour).

One could wonder who is supposed to do splitting big projects to smaller chunks? How small those chunks should be and how to know if all tasks were accounted for.

I firmly believe that the founder must work on User Experience herself. Before starting the project, I would advise to use wire-framing tools and build all pages as detailed as possible. Suggested reading on UX process here.

Once the user interface is more or less clear you will need technical help on the further deconstruction of tasks. The reason for technical help is simple – most of the work is done behind the scenes, what users see often is a tip of the iceberg in terms how much work should be done to run the application.

Even a simple application needs to have storage (often in the cloud) to save user information, integration with email/SMS and other notification services, etc. Without technical support, the non-technical founder is unlikely to be able to identify server-side tasks.

How to get technical help?

If you have a team of programmers or outsourcing partner then you can work with them. If not, then you need an expert, preferably someone who has built something similar.

Not everyone has a friend who worked in Google or Facebook, so the simplest solution for finding tech talent could be Upwork or similar freelancing web site. I will review how to find a freelance expert in later posts.

How to estimate individual tasks?

There are 2 main ways to estimate individual tasks: ideal hours or points.

The first option is probably most easier to understand: when developers tell you how many hours it will take them to implement the feature assuming they are not interrupted and only work on this specific feature.

Usually experienced project managers understand that nobody works all 8 hours even when a person shows up for 8 hours in the office. Good PMs assume that in any given day a developer can fully focus on less than 6 ideal hours. However, it doesn’t mean that the outsourcing company will charge for 6 hours per day.

As I already explained earlier there is no way a developer can accurately predict that adding a new login page will take him exactly 6 hours and 23 minutes. But without any doubt, he can tell you is that it will take longer to implement user management module than login page.

So instead of using ideal hours, you can use a point-based system. There are many different variations of point types, but they all have some so non-linear dependencies between points and size of the task.

The most common example is a T-Shirt sizing.

When using T-Shirt sizing one assigns XS to the very small task (under 2 hours), S for less than a day tasks, M for 2-3 days ones, L for up to a week, and XL for up to 2 weeks.

One of the advantages of this system is that it allows you to quickly see if you over-detailing (too many XSs) or under detailing (too many XLs. Ideally, most tasks should be S, M and L. Anything bigger than L should be broken down to smaller pieces.

Alternatively, you can use Starbucks cup sizing: Tall, Grande, Venti and Trenta, or Fibonacci numbers: 1, 2, 3, 5, 8, 13.

Estimation Methods

After choosing a sizing type for individual tasks you need to decide on estimation methods. Again, there are many methods and in this post, I will review 2 of them: Planning Poker and Expert Estimation.

If you have a team of developers (not outsourcing company) with whom you developed software before using poker planning technique is the best for getting most accurate effort numbers. In short, when using this technique each member gets a set of cards: XS, S, M, L, and XL.

When reviewing tasks each member calls their cards simultaneously. If every member reveals the same card the tasks get assigned a size agreed by all. In case if someone thinks that the task is too small or too big, he or she should explain the reasoning behind the decision. After discussion team will vote again until they reach consensus.

The Planning poker method works only with teams that used to work together which is likely not the case for readers of this blog.

The Expert estimation is a traditional strategy which will be used in most cases. With this method, people who work on implementation should assess the complexity of the tasks and assign the time (or points) accordingly.

If the outsourcing vendor is doing the work then they have to provide estimates. If you didn’t pick outsourcing company and didn’t hire developers directly then you can invite an experienced architect (or full stack developer) to provide estimates.

In latter case remember though that the estimates may be off as I pointed in reason #4.

Review

Once you have all time and financial estimates it’s time to review the requirements again and prioritize MVP features. One prioritization technique is MoSCoW method. According to this method, all features can be put in one of four buckets: Must have, Should have, Could have and Won’t have.

Must have is a feature that sets your solution apart from its competitors. This is one feature where you should spend most of your time perfecting. This feature alleviates your customer’s pain. For Dropbox it was synchronization, for Evernote it was a Web Clipper (I installed Web Clipper first and then Evernote app).

Should have features are important, but not 10x features like the Must have one. Frankly, the difference between must and should is not very clear. In most cases Should haves are features that make Must haves even better. Fortunately, if you can’t identify Should have features it’s not a problem – don’t put anything into this bucket if don’t need to.

Could have features are nice to have ones, but not critical. If you have time and resources, then you may invest in them.

Won’t have features are those that you definitely not putting in the current version of the software.

The difference between MVP and the final product is that the former must only include Must have functionality. If the MVP does one thing better than all competitors than there will be customers. If you can’t figure out what is a Must have in the MVP maybe you need to reject the initial idea.

Execution

All the work you did so far was needed to identify how much money you can spend on building your product.

If you have a limited budget (as most people do) I would suggest spending it on Must and Should have features.

If you don’t have enough money for Must haves, then it’s time to raise money from family and friends. And remember: projects don’t always go as planned, so budget 30-40% more than developers quoted.

And start building from what makes your product most valuable, i.e. if you are building Word processor start with the editor and work on Clippy Office Assistant only when you have spare resources.

Alisher Abdukadirov

Alisher is an experienced developer and software development manager. He has a lot of experience managing offshore development teams.

Leave a Reply

1 × four =

Close Menu