How to Estimate Software Development Time [best practices]

Almost 70% of projects are built with schedule overrun and your project may be one of those, too. Isn't it annoying to spend more time than planned? You would also like your project to be delivered on time while meeting market demand, wouldn't you? That's why software development time estimation should be a priority in simplifying the work and making. We've compiled a list of the basic steps to take to get a realistic software development time. Keep reading to see how the time estimate is made.

Why you need to know software development time

It’s necessary so that you know how long (estimated in hours) it will take to get your project done. This can be compared to house renovation... Oh, no, not that, that's too complicated. Okay, let's compare it to a flower shop. Yes, it's a much better choice.

Let's say you want to start a flower shop and want to do budget and time estimation:

• You calculated how much/long it would take to start a business.
• In the process, it turns out that the flowers you want are not available. You need to replace the planned product with another one, and it takes time.
• Then it turns out that the flowers need to be stored under other conditions. Your equipment needs to be replaced.
• The flower shop isn't open yet, but you already realize that you need to sell coffee and books here as well.

Do you see what's going on? Well, yes, business requirements can change, as well as the originally estimated time and budget. And it's not about flowers anymore, it's about your software solution.

Benefits you get from development time estimation

What you get as a customer:

• You'll have a clear idea of when you'll get the product delivered. This is of particular importance if a product presentation or a major corporate event is on the horizon.
• You can put your mind at rest knowing that you'll meet your deadline.
• You have full control over the process and are aware of changes in the time estimate or budget, as well as their consequences.

The advantages a software development team gets:

• We can allocate tasks/resources intelligently and in advance, as well as manage deadlines and workloads.
• We get an idea of which specialists should be involved and at what stage.

Why is it difficult to get a true software development time estimate?

Although there are obvious benefits, time estimation is still not that different from prediction, as it's done mostly intuitively. Software developers use their own experience in deciding what's difficult to implement and what's not. The more qualified the programmer, the higher the chances of getting a correct time estimate.

But this way of estimating development time also has its own nuances. Previous experience and a proven approach can be tricky when faced with unfamiliar problems. No developer is immune to potential problems with architecture, frameworks, library access, and tech community support.

And what about human factor? The programmer - that's right, even the senior one! - may get sick or take a day off. Of course, it's not your fault if the programmer can't be done by tomorrow morning. But there may be unplanned extra tasks on the client-side that disrupt the time estimate.

To sum up, development time estimation can go wrong because of aspects as follows:

• Irrelevant experience;
• Unpredictable technology-related problems;
• Human factor.

What to do about it? - you might ask. Use a well-thought-out approach and proven methods to get things right.

How to estimate development time: phases to consider

To find out the total software development time, the expected development process should be divided into stages. Then estimate how long each stage will take and summarize the data.

Discovery stage

At this stage, the developers involved need to get as much information about the project as possible. Prototypes and frameworks are also prepared at this stage. If it turns out that there is work that needs to be done using sophisticated technology, we have to allocate enough time for it.

Thorough requirements discussion is worth including in the Discovery stage when estimating development time.

How it works:

• Developers receive the requirements from the client and scrutinize them for logical gaps.
• If any questions arise, they are discussed further.
• Developers draft a general document detailing the requirements and agree with the customer on it.

A document with well-defined specifications is used as a guideline for everyone, as it prevents the "didn't we agree that the application would have this feature?" situation. Let's face it, it is much cheaper to fix a problem in the planning phase rather than when the product is finished.

Software architecture design phase

The scalability of a product is affected by how consistently the system architecture is planned and designed. This should be considered when estimating software development time. The current phase involves selecting the technology stack, class diagram, database, libraries, APIs and phasing of each stage.

Development stage

To be effective, it needs to be broken down into separate logical stages so that you can monitor the team's progress and performance. The product development process can take from 2 to 12 months. This should be considered when estimating software development time.

Testing stage

No product can be considered complete if it hasn't been thoroughly tested. Moreover, a software solution must be tested from the beginning. Why? Possible bugs will be cheaper as they're discovered and fixed sooner. The testing stage is included in the time estimate.

Extra time: buffer time and time-eaters

Consider unplanned or unobvious aspects of the work that may affect the timeline. They make up from 5 to 25% of the total development time estimate:

• The unpredictability of technology;
• Integration or scaling issues;
• Conflicts of interest within the team;
• Meetings, calls, approvals;
• Productivity loss, etc.

How to estimate hours for a software project

This is usually done on a task-by-task basis, which simplifies the work and makes the result more transparent. One way to estimate development time is to estimate how long each expert can spend on the project.

This approach focuses on the amount of work that the average* IT professional is capable of doing in one hour**.

*Average IT specialist means that he/she is a mid-level technical specialist (developer, designer, QA engineer). They perform tasks related to their specialization. This means that the time it takes to complete a testing task should be estimated based on the performance of the QA engineer, not the front-end developer. A mid-level engineer may not do the job as quickly as a senior programmer, and he or she is likely to be more productive than a junior technician.

**An hour of work means 60 minutes of continuous work. It's important to understand whether the work of this specialist depends on the output of other specialists, whether he or she needs to wait for someone else to do his or her volume of work.

Let's see what approaches and practices can be applied to estimate software development time. The most common approach is the Agile methodology.

Let's outline the key subject-related terms:

• User story: it's a 1-2 sentence description of what the system should do;
• Story description: a measure of the amount of effort (not in hours) required to complete the User story;
• Backlog: a list of tasks to be done to achieve the goal.

Now let's move on to the actual practice of estimating software development time.

Software development time estimation methods

Everything seems clear enough with the development time estimation. But... don't you think something is missing? How is this estimation done?

The basic methods are described below.

Bottom-Up approaches or sticking to milestones

When the total development time is known, technicians may overestimate their performance and thus overrun their time. Avoid the problem of time overruns by dividing all tasks into stages and estimating each stage separately. That is, by following the "bottom-up" principle.

There are usually two specialists involved in the time estimation:

• Developer. He/she prepares a specification describing all the tasks; divides them into groups or subtasks and estimates the development time.
• An independent specialist of the company (e.g. a senior project manager). He/she checks the time estimation results provided by the developer to see how realistic they are. If necessary, adjustments are made.

Planning poker

This approach to estimating software development time involves principles similar to those of Agile methodology and poker. How does it work?

• The client voices the task facing the team.
• This information is discussed within the team and follow-up questions are addressed with the client.
• A backlog with tasks is created.
• Team members get together to find out how long it will take to perform tasks from the backlog.

Estimating the software development time using Planning poker looks as follows.

Each developer gives his or her estimation of the task at hand. To do this, they use cards with numbers. Each team member has a set of cards with values 1, 2, 3, 5, 8, 13, as well as 21, 34, 55 (according to the Fibonacci sequence) or 20, 40, 100 instead of the last three. Besides, there are three cards without a number. They contain an infinity sign, a question mark, and an image of a coffee cup.

Each User story is scored with one card, the value of which is equal to the estimated amount of effort needed (Story points). A card with the number 1 means the User story is easy to complete. The further away from 1, the more difficult the User story seems. An Infinity card represents the highest level of difficulty.

If the numbers chosen by each developer are the same, it means that the estimation of effort needed is done correctly. In case of disagreement, the final scores are clarified during team discussion.

This step isn’t purely about estimating software development time in hours. Only story points are defined so far. To have an idea of how this is represented in hours, you need to know the hourly value of the story point.

It's important to note that Poker planning is about discussion. Just imagine - true experts are involved in your project. Each of them argues their choices, and the details of the project are thoroughly discussed. Chances are you will get an accurate time estimate.

Experience-based approach

This approach requires a comparison of the new project with a similar one among previous projects. In this case, you need to start with the time it took to implement it. It's also necessary to find out the level of difficulty of both. By multiplying the number of hours by the difficulty factor of the previous project, you can estimate the development time regarding the upcoming project.

Project estimation in figures

Let's turn to the following examples to make the above information illustrative.

Overall time estimate (OE) + OE*Buffer time + OE*Time-eaters = Software development time

Let's put in some numbers (numbers are approximate):

5000 (OE) + 5000*20% + 5000*20% = 7000 hours.

Let’s go further.

Imagine that we need to implement the "Multiple Accounts" option on Instagram. To do this, we need to think of all the possible actions that users can take:

• He/she wants to add an account.
• He/she can select the "Log in to existing account" option, which requires him/her to enter a username and password or log in through Facebook.
• The user may forget his/her access or find that he/she is not authorized on Facebook.
• The user can select the "Create new account" option, after which the system will require him or her to go through the registration steps.

Given the differences in user behavior, you can define a list of tasks that developers need to complete so that users can add a new Instagram account. What this looks like in terms of tasks, technicians, and time estimates:

• Design a page with all the necessary fields and a comprehensible user scenario.
• Make sure the user is authenticated by finding out if he or she is allowed to access the requested pages.
• Make a redirect according to the authentication result: to the requested Instagram page, to the Facebook page to complete authentication through Facebook, to the page with an authentication error, etc.

As a result, it would take 13 hours of technicians' work for a user to be able to switch between multiple Instagram accounts. Keep in mind also the project manager who coordinates and manages the process (e.g., 3 hours).

Bottom line

Software development time estimation may seem easy to perform at first glance. However, it requires time and a full immersion of technical talent. To make sure that both you and your IT service provider are satisfied with the result, you need to properly estimate development time from the beginning.

It's helpful to involve an entire development team. Their experience leads to the most realistic time estimate possible. They also estimate the project based on their capabilities. They are unlikely to be willing to work overtime if it turns out that the time estimate is wrong and the team is behind schedule. It's in the interest of the developers to provide you with the most accurate data possible.

With that said, we hope you now have an idea of why a clear time estimate is needed. With it, you'll be able to control the budget and the process, avoiding unpleasant surprises.

If you don't know yet how to estimate the time it takes to get your product ready, drop us a line to discuss it.