PRODUCT STRATEGY

How to Estimate Software Development Time Accurately?

Published: September 1, 2023

11 min read

When we at Stormotion start working with a new client, he usually asks us to make a software development time estimation. We also prepare it for our potential customers who drop us a letter with details about their project and willingness to cooperate.

However, time estimation in software development isn’t that fast & easy as it may seem. This process requires experience, knowledge and includes hidden pitfalls which we’ll teach you to avoid today. Let’s start!

Despite it may look simple, an estimation process is quite a challenging task (*image by [Lukáš Straňák](https://dribbble.com/LukasStranak){ rel="nofollow" .default-md}*)

Despite it may look simple, an estimation process is quite a challenging task (image by Lukáš Straňák)

If you already know all benefits of a good estimate, move right to the practical part!

🤔 Why Do We Need to Estimate Software Projects?

Properly made software estimations are quite useful at the planning stage and further. They allow developing a realistic scale of efforts required on a specific project-phase. This usually includes:

  1. The time needed for the development.
  2. The number of people who should be involved into the project to deliver it on time and their positions (FrontEnd/BackEnd Developers, QA Engineers and so on).
  3. The budget range for the Web- or Mobile App (usually calculated as the development total time multiplied by an hourly rate).
Estimates provide many useful info (*image by [brian hurst](https://dribbble.com/bhurst){ rel="nofollow" .default-md}*)

Estimates provide many useful info (image by brian hurst)

As a rule of thumb, software development time is the number of hours which will be required to implement a requirement of the Product Owner. Such a requirement can be for example: a feature, a user story etc. The sum of hours needed to implement all the requirements makes up the estimate of the whole app.

Why do you need this info?

Estimations are quite useful for all kinds of projects, including the ones that use agile-based frameworks.

Despite the classic Scrum approach doesn’t have an estimation stage in its structure, this kind of information turns out to be extremely helpful when you need to distribute features from the backlog between sprints for your remote team.

Scrum sprints usually aren’t changeable after the work starts. It means that estimates can help your Product Owner prioritize feature development and group them in such a way that allows delivering an increment on time.

Estimates help correctly prioritize feature development (*image by [Austin Golownia](https://dribbble.com/agolownia){ rel="nofollow" .default-md}*)

Estimates help correctly prioritize feature development (image by Austin Golownia)

The same is true for the Kanban framework!

Since it’s based on the idea of continuous development, your team should constantly have enough tasks to keep working. The main challenge for a Product Owner is to prioritize them according to the business goals, deadlines, available resources etc.

But to prioritize it correctly, you’d better know how much time and efforts development of each feature can take. That’s when a good estimation comes in handy! With its help you’ll be able to create a development queue that matches your capabilities.

Moreover, since cycle time is a key metric for Kanban teams, an estimation will let you check whether the team does well or goes off the track.

Let’s review several real-life examples from Stormotion clients:

📂 Case

✅ How software development time estimation helped

One of our clients got a limited Angel Funding – €30,000. Is it enough to build an app MVP?

An estimation provided him with info on both total development costs as well as the price of each specific user flow. Thus, he found out that his budget meets all his needs and none of the features should be removed at the MVP-Stage.

An e-Commerce needed to convert a mobile app from iOS to Android. What is the best way to do so?

After estimating software development time, we found out that the development required 2.5 months with next support on a 10-hours-per-week basis.
So we recommended him working with an agency (since it was more reasonable) which saved him money in the long run.

Our German client needed to hire a remote developer to supplement his In-House team for one specific project.

Our estimation clarified the scope of work, helped to understand the needed amount of time to perform all the tasks and, therefore, correctly plan the budget and timeline for the project.

How Can Software Estimations Be Useful for Both Parties?

Estimates provide value to both sides of the development process in one or another way:

👩‍💼 For the client

👨‍💻 For the team

Provides info on the approximate time required to complete the project. This is especially important for projects with strict deadlines (certain promises to customers, a planned presentation during a particular industry event).

It helps to delineate the scope of the work and set adequate deadlines inside the team.

Provides info on the approximate cost range of development (and whether it fits the current budget).

Used to define the optimal number of developers needed to do all the work on time according to the contract.

Allows both parties to manage budget expectations - client knows the budget in the best and worst case.

Software development time estimation helps to calculate planning metrics (like cycle time in Kanban or velocity in Scrum).

As you can see, a good estimation provides some value to all shareholders. However, creating one isn’t an easy task. Let me explain why.

📉 Why Is It so Difficult to Make a Perfect Estimation?

Despite many call estimations none other than predictions, they’re not the same as unjustified guesses. A correctly prepared estimate is always based on knowledge and experience of the team who is writing it.

However, when you try to estimate time for software development, it sometimes looks like this:

  • How much time would it take to ride from point A to point B?
  • 2 hours.
  • By bicycle.
  • 6 hours.
  • On a country road.
  • 8 hours.
  • It’s a moonless night.
  • 10 hours.
  • It’s snowing.
  • 12 hours.
  • You haven’t slept for 2 days.
Estimations sometimes look like that story about the bicycle ([Zamir](https://dribbble.com/zamirbr){ rel="nofollow" .default-md})

Estimations sometimes look like that story about the bicycle (Zamir)

This story can go on and on, and the estimation will change every time when the new condition is set. And this is what often happens when you’re estimating software development time.

So, the first reason is that any developer doesn’t have a 100% protection from unforeseen issues with performance, libraries, environment, architectural imperfections, APIs integration and so on.

However, unforeseen issues don’t relate only to the technical side. We’re all human beings that can get sick, have an emergency case or anything else.

Second, it may be difficult to estimate time for software development because of estimator’s individual characteristics. Every developer, depending on his experience, knowledge, general productivity and even physical or mental state at this exact moment will have a different working pace.

*Image by [Aleksandar Savic](https://dribbble.com/almigor){ rel="nofollow" .default-md}*

However, it’s quite reasonable that clients shouldn’t pay 3 times more because someone works 3 times slower than an average developer. To prevent this, estimates are usually reviewed and corrected (to be more justified) by a more experienced tech-person (as a rule of thumb, a Senior).

Third, it’s difficult to estimate software projects precisely because sometimes changes come from the client’s side, too. For example, you decided to implement additional functionality or, on the contrary, to remove some pre-planned features.

However, all of the above doesn’t mean that it’s absolutely impossible to make a credible time estimation in software development. Look how this process is organized in our Stormotion HQ!

✅ How Do We Estimate Time for Software Development in Stormotion?

Since after an initial call we’re replying to all estimation requests which we receive - our team has designed a specific workflow for answering them.

Step 1: Preparation

Before estimating software development time we need some input - information that can help us understand the ground features of the project.

At the first stage we gather as much information as possible (*image by [maryanne](https://dribbble.com/maryannemade){ rel="nofollow" .default-md}*)

At the first stage we gather as much information as possible (image by maryanne)

We usually get it from 2 main sources:

  1. From the data provided by the client: this includes Mockups, Wireframes, Use Cases, User Stories etc.
  2. From the client itself: during an initial video call via Skype or Hangouts - we discuss the project in general and update details.

Then our tech-crew processes all this data and uses it to draw the first version of the estimate - a rough one.

Step 2: Rough Estimate

This kind of estimate is usually prepared within 24 hours and consists of 2 parts - Min and Max Estimates (or Best Case and Worst Case Scenarios).

Since it’s prepared using limited info about the project, it’s difficult to provide the client with a 100% accurate breakdown. Instead, we offer 2 figures that indicate both the highest and the lowest possible development time and costs.

Rough estimate provides many benefits to both developers and clients (*image by [Laura Reen](https://dribbble.com/laurareen){ rel="nofollow" .default-md}*)

Rough estimate provides many benefits to both developers and clients (image by Laura Reen)

The more information we manage to gather during the first step, the better our estimate is going to be. It will let us face a lower level of uncertainty and, thus, reduce the range between the highest-lowest figures.

Tip: If you earlier had an experience with a project similar to the one you’re working on now, you may compare them and use it as a ground for your estimation. When reviewing the old project, take into account actually spent (and not estimated) time.

Rough Estimates are essential for our clients since they help to understand the real scope, length and budget range of work.

Then, if everything is fine and our calculation matches the client’s budget - we’re either moving to the Discovery Phase (in case there are some tech-challenges which need deeper research) or move to signing the contract right away.

Step 3: Discovery Phase

Sometimes, if the client has no info about the project except some use-cases (e.g. no wireframes), or there is a hard API or technology, which we need to research before giving a cost-indicator we propose our client a Discovery Phase, which lasts 1-2 weeks.

During this time we hold a few more video conversations with our client, develop our own wireframes, prepare an interactive Marvel/Invision prototype (like the ones in our article about Pocket Promoter and Hotel App Development).

During the Discovery Phase we examine the project from A to Z (*image by [Nick Slater](https://dribbble.com/slaterdesign){ rel="nofollow" .default-md}*)

During the Discovery Phase we examine the project from A to Z (image by Nick Slater)

Also, we pay special attention to tech challenges that may occur during development - for example, how we’re going to implement machine learning side or integrate non-common APIs.

Pro’ estimation software development tip: if any task takes more than 8 hours we split it into sub-tasks. When making a Rough Estimate we try not to exceed the limit of 30 hours for 1 task.

Eventually, our client receives the final detailed version of the software estimate with the most realistic figures.

P. S. We’re going to dedicate a special article to the Discovery Phase so stay tuned.

⚙️ Top Estimation Software Development Approaches

Now we reach the part of the article with practical tips. This is what you came for, isn’t it?

Despite estimations always have a single aim, ways to reach them can be different.

Approach # 1: Classic One

The first approach is the most common and widely used since it’s pretty fast, easy and understandable. It usually involves 2 people: the one who will work on an app and the one who will do the estimation of software development (preferably a person not related to the project).

Why shouldn’t it be a single person? Despite it may seem quite logical that the estimation is done by someone who will then work on this project (since this person understands own capabilities better than anyone) this is not the best approach.

The classic approach is one of the most used across the globe (*image by [Anton Fritsler (kit8)](https://dribbble.com/Frizler){ rel="nofollow" .default-md}*)

The classic approach is one of the most used across the globe (image by Anton Fritsler (kit8))

The problem is that when developers estimate software development time of their own projects they’re usually disposed to put more hours than it really takes. Actually, it doesn’t even matter why it happens - because they just want to work more slowly and get more money from you or because they want to have additional time to solve unexpected issues.

For example, estimating the fitness app development cost can offer insights into budgeting for similar unforeseen challenges.

So the best solution is to involve another tech-guy, who can write the estimation for the person which will perform the work.

This specialist should be more experienced (a Junior/Middle can’t make an estimation for a Senior, but a Senior can make one for both of them) and interested in an objective result. His workflow consists of the following steps:

  1. Clearly understand the scope of work. The developer should list all the tasks in any convenient form - in general or split them into groups of sub-tasks.
  2. Estimate software development time for each feature, taking into consideration experience, productivity and other characteristics of the person who will work on this project.
  3. Sum up the numbers and check whether the final figure for the whole project looks realistic.
  4. If needed, review it once more together with the developer and make corrections.

This approach is widely used by our team as well.

P.S. It’s also possible for an estimate to be written by someone who will then work with it, but it always should be checked by another, more experienced and objective person.

Moreover, as you could notice in our articles about app development, we usually try to break down the tasks into smaller sub-tasks to make our rough project estimates more accurate. Take it as a tip 😉

Approach # 2: Planning Poker

If you have a few developers working on the same project, the classic approach may work not that well. Instead, you can ask your Agile team to prepare software development time estimation jointly.

Such an approach would be called Planning Poker or Scrum Poker.

In this case, each developer has special cards with values on them (for example, 0, 1/2, 1, 3, 5, 8, 13, 21, 34, 55, 89). The numbers represent Story Points or any other items that indicate how difficult/long it is to create the feature. Later these cards will be used for voting.

An example of poker planning cards (*image by [Andrew Millar](https://dribbble.com/andrewmillar){ rel="nofollow" .default-md}*)

An example of poker planning cards (image by Andrew Millar)

The whole estimation software development process goes as follows:

  1. The Product Owner describes a feature or presents a User Story to developers.
  2. Estimators discuss the feature, ask questions to the Product Owner.
  3. When the discussion is finished, each developer privately selects the card to estimate the feature.
  4. Cards are revealed. If all estimators have chosen the same cards, that figure becomes the estimate. If there are some differences, they’re discussed and then voted again and again until all the estimators don’t pick the same value to estimate the feature.

It’s important to notice, that all the decisions are made by discussing and through consensus - not by averaging all the values after the first round.

Scrum Poker has a few significant advantages which turned it into one of the most popular software development time estimation techniques:

  • First, it brings together several experts - each with his unique experience - that helps estimate even the most complex tasks.
  • Second, since all the results are achieved through a dialogue, this approach improves the accuracy of the estimates and justifies it.

🎁 Bonus: Ready-Made Software Estimations by the Stormotion Team

Our regular readers and newsletter subscribers know, that each Stormotion’s article about app development is supplemented with an estimation.

As we mentioned it earlier, these estimations are true only for our developers and only for the apps described in the articles. If you want to see the full detailed estimation, click on the name of the app and you’ll be redirected to the appropriate page:

App

Approximate Time (in hours)

🚙 Car Navigation App Like Waze

1030

💬 Snapchat Clone App

1295

👛 App For Retail Business

440*

🏨 Hotel Booking App

425*

🛵 Food Delivery App (customer, courier and web apps)

509; 334; 139

🍽️ Restaurant App

412-526*

👩‍⚕️ Doctor Appointment App

660-850

🏡 Real Estate App Like Zillow

648*

490-688*

340-790*

💸 Bitcoin Wallet App

560*

🎉 Event App

435*

❤️ Dating App Like Tinder

922

360*

*- without BackEnd

💡 Takeaways

These were our insights on time estimation in software development. They will be useful for Agile teams no matter what framework - Scrum or Kanban - they use. Also, estimates are helpful to use as a bussines owner since they make the scope of work and possible budget more understandable.

If there are any questions left, feel free to drop us a line!

We hope that our experience and tips will help you to create a perfect estimate for your future projects. Also, don’t forget that you can get a free estimate from the Stormotion team within 24 hours. All you have to do is just contact us by hitting the button below.

Estimate Your Project in 24 Hours!

Read also

How can we help you?

Our clients say

Stormotion client Max Scheidlock, Product Manager from [object Object]

They understand what it takes to be a great service provider, prioritizing our success over money. I think their approach to addressing ambiguity is their biggest strength. It definitely sets them apart from other remote developers.

Max Scheidlock, Product Manager

HUMANOO