How to Estimate Software Development Time Accurately?

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!

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.

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:

How Can Software Estimations Be Useful for Both Parties?

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

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.

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.

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).

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.

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.

*- 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.