How to Become an Expert in Software Estimates: Practical Tips to Get a Realistic Project Estimation

The first thing most clients ask us to do at the beginning of the working process is to conduct a software development time estimation. It is ok, we prepare the document of this kind for our might-be customers, who dropped a letter to our team regarding the willingness to cooperate.

But time estimation is not that fast or easy as it is considered to be. Of course, it requires a certain level of experience to begin with. The process includes hidden pitfalls, which we will have a look at today and learn how to avoid. So, let’s go.

By the way, if you already can name the benefits of accurate time estimation, you can move to the next section right away.

Why do you need software development estimation?

During the planning stage and even further in the development process time estimation is a useful technique. It allows developing an accurate scale of efforts required on a specific project phase. The points, covered during the time estimation process, are mainly the following ones:

1. Total development time.
2. The number of the team members involved so the project can be delivered on time.
3. The positions of the involved team members –developers, both frontend and backend, QA engineers, and so on.
4. The budget. As a rule, it is calculated based on the development time, being multiplied by an hourly rate.

Development time is considered to be the number of hours, required to implement all the requirements, stated in the brief, provided by the Product Owner. Among the requirements can be, for example, a certain User story, a specific feature, or UI element. So the estimate for the whole app will be the total amount of hours needed to implement all these points and requirements.

What kinds of projects need effort estimation?

All kinds of projects need estimation, no matter what methodology they use. Thus, agile-based frameworks require accurate estimation as well.

If you say that the Scrum approach does not have an estimation stage on its own, you will be correct. But this information will become mush in hand when the features from the backlog need to be distributed between sprints for the team, working remotely. Yet Scrum is flexible, the sprints aren’t changeable when the work finally starts. Time estimation will help the Product Owner to pick the features to be prioritized and group them into sets. That will help to deliver the product in time with all the basic features being implemented.

It works for Kanban too, even though these approaches have substantial differences. Kanban is based on the concept of continuous development. It means that the team has to have enough tasks so the workflow can run smoothly. So the challenge the Product Owner faces is again to prioritize them, so the business goals will be achieved, all the deadlines met and available resources used.

In case the prioritization stage is completed correctly, it is easy to see how much the development will take. So accurate estimation turns out to be in hand, right? In other words, estimation helps in prioritization, which, it its turn, allows to creation a development queue. In this case, the development capabilities of the team should be taken into account as well.

But when we are talking about Kanban, estimation here turns out to be even more important because time is the key metric. It means that one can monitor if the team is doing well or not based on the estimation figures.

How can software estimates be useful for both parties?

Software development estimation is useful for both parties, involved in the development process.

For the client

For the team

The client gets data regarding the approximate time
needed to complete the project in front of him. It is
critically important for the projects, operating within
strict deadlines. For example, it can be certain
promises to the customers, planned presentations,
or upcoming announced updates.

The scope of the work can be easily delineated,
so it is easier for the team to set appropriate
deadlines.

Allows to get a clue regarding an approximate cost
range, so it can be checked to fit the available budget.

Makes it easier to define the number of the team
members so all the work can be done in time and
within the terms, specified in the contract.

Budget expectations can be easily managed.
In other words, the client can see what to
expect in different cases.

Profound estimation can help to calculate the metrics,
including cycle time un Kanban or velocity if the team
is using Scrum.

All the shareholders can get some profit from a correctly conducted estimation process. But it is not that easy to do properly. And below we will discuss why.

Why is it so difficult to make perfect software estimates?

There’s an opinion that all effort estimations are just predictions, nothing more. But predictions are not the same as unjustified gestures. The difference is, that the estimation is always based on the knowledge, experience and analysis.

But sometimes when it comes to the time estimation in software development, it can look something like this:

How much time would it take to reach point B?
2 hours.
On the horse.
8 hours.
In the wood.
10 hours.
At night.
14 hours.
It’s raining.
16 hours.
You are blind.
…

It can go on and on, so the estimation time changes all the time, as well as conditions do. And when you are working with the time estimation for the development, it happens too often to be just a coincidence.

The first and foremost reason is unexpected issues, and developers are not 100% protected against them. So the issues can be related to performance, environment, imperfections of the initial architecture, libraries, API integration, and many, many more.
But unforeseen issues appear not just on the technical side. There’s always a human factor – we all can get sick, have a case of extreme emergency, or anything else.

There’s another case when it becomes difficult to conduct the time estimation process correctly – when the estimator’s individual characteristics are involved. The working pace is different for each and every developer and depends on his knowledge, experience in the field, mental and physical state at the very moment when the estimation takes place.

The client shouldn’t pay three times because this particular developer works three times slower than another one. Technically, it’s not the client’s problem. There’s a way to prevent it by correcting end reviewing the estimates by a more experienced person. Usually, Seniors conduct this piece of work.

Another reason why it becomes difficult to estimate the development process is that the changes can come from the client’s side. The most common example is introducing additional features or refusing some functionality.

But all the mentioned points do not mean that it’s impossible to make an accurate estimation. In our company the process is well-organized and we will share how we actually work on time estimation.

How do we estimate the time for software development in Celadon?

We reply to all the estimation requests, and because we get a substantial amount of them, the team has designed a detailed workflow and algorithm for answering them and processing the requests effectively.

Step 1: Preparation

For time estimation there’s one thing that is 100% essential – the input provided before the estimation process starts.

There are two main sources where we can get the input from:

1. The client’s initial project ideas. The client provides the initial data, including Use cases, User stories, Mockups, and Wireframes.
2. From the client himself. While Skype calls or during the Hangout we discuss all the matters, the project, and possible update details.

After the data is collected, the tech-team processes it and presents the first brief version of the estimate. It is rough and not that precise but can be already used in some cases.

Step 2: Rough estimate

The rough estimate can be prepared within 24 hours. It generally consists of 2 parts which are MIN and MAX estimates. They are called Best and Worst-Case scenarios as well.

Here one point has to be mentioned. Being prepared using the limited data regarding the project, the rough estimate should not and cannot be considered a 100% accurate breakdown. Instead, rough estimation is basically just two figures, indicating the highest and the lowest development costs and time.

The rule is simple here – the more information we have and are working with, the more accurate the estimates will be. Thus we face a low level of uncertainty and can reduce the gap between the highest-lowest figures.

Tip: If you already have experience with a project similar to the one you are working with, you can use it as a background for estimation if there are enough similar points. But when you are relying on the previous project, remember to look at the time you already spent but not on the time which had been estimated back then.

It might seem that rough estimates are not that important as fat they are not 100% accurate. But even though they help to understand the real scope and at least have a notion of the budget, as well as a range of work.

If everything is OK, the calculations are within the budget we can move forward to the Discovery Phase if there are some technical issues that appeared and need to be fixed. When this step is completed, we move straight to signing the contract.

Step 3: Discovery phase

There are cases when clients do not have much information about the project and everything he possesses is just a set of use-cases. Or, for example, a hard API or some sophisticated technology is involved, we can offer a client Discovery Phase. It can take an additional week or two while we are conducting an investigation.

We hold more video conversations with the client, develop needed wireframes, prepare prototypes. During this time, we also pay close attention to the technical challenges appearing during the development process. The most common example of such a challenge is machine learning implementation or non-common API integration.

A tip form pro: In case a task takes more than 8 hours, it is divided into smaller sub-tasks. During rough estimation, we try to fit the limit of 30 hours for one task.

After this phase the client gets the detailed version of the estimates with more accurate figures.

Top effort estimation techniques

It’s time to get to the point and have a look at some practical tips. Honestly, we all came here for it, right? There are different approaches to estimations, but their aim is the same regardless the approach.

1. Old good classic

It is most common because it can be conducted quickly, it is easy and simple for understanding. Two people need to be involved, so one is working on the app and another one conducts the estimations. Opposite to the common idea, this second person should be the one, not related to the project.

But why should it be like that? It seems logical so the person, doing the estimation, will work on the project further. This person understands his own capabilities and other factors, so why this approach considered to be not the best one?

The thing is, when the person estimated the development process, taking into account his own abilities, he usually puts more hours than it will take in reality. The reason is simple: people tend to work slowly and get more money as a result. Another reason is that the developer wants to have more time to make sure all the unexpected issues will be solved.

It means it is considered to be a better practice to involve another technical specialist, so he can make an estimation for the person working on the project.

Of course, this specialist has to have more experience (a Senior can make an estimation for a Junior or a Middle, having more experience). The workflow can have steps like that:

1. Distinguish the scope. All the tasks should be listed in any form, considered to be convenient. So they can be divided into sub-tasks if considered to be huge ones, or taken in general for smaller issues.
2. While conducting the estimations for each feature, the responsible person should take into account a lot of points, including productivity, experience, and other characteristics of the developer, whose task will be to work on the project.
3. To check the figures and see if they look realistic enough for the whole project.
4. It is recommended to review the estimations with the responsible developer and make corrections if needed.

Our team also uses this approach because of it’s being extremely efficient.

Even if the estimations are written by the person, responsible for working on the project, the final figures and numbers have to be reviewed by another specialist, having more experience and being more objective.

As you can notice from our other articles, we usually divide tasks into smaller ones, so-called sub-tasks. It allows us to make our project estimates more accurate. It can be taken as a tip as well.

2. Planning poker

The previous approach works fine when you have one developer, working on one project. But in case the project is huge and there are a couple of developers involved, this approach will not work as desired. In this case, development estimation time can be made jointly.

This approach is known as Planning poker or Scrum poker.

So each developer gets a card with values, for example, 0, 1/2, 1, 3, 5, 8, 13, 21, 34, 55, 89. These numbers stand for Story Points of other values, indicating the difficulty of the feature creation. These cards can later be used for voting.

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

To cut it short, the estimation process can be described as a set of the following steps:

1. During the conversation with the development team, the product owner describes the features to be implemented or provides the developers with the User stories.
2. The developers, responsible for the estimation process, clarify the details if needed by asking additional questions to the customer.
3. As soon as the discussion is done, developers pick the card to estimate the feature.
4. After the cards are revealed and in case all the developers picked the same card, the mentioned figure will be considered as an estimate. If there are different cards, this situation is discussed again, developers vote and check the result. This process can go over and over again until each member of the team picks the same card.

Note! All the decisions are made through discussion and consensus only. Averaging the values is absolutely inappropriate.

So why Scrum poker is so popular? What are the advantages, that have made it one of the most popular approaches in Agile teams? Let’s have a look.

• The tasks, even the most complex ones, are estimated not by one developer, but by several experts, possessing their own experience and having a different background.
• The estimation becomes more accurate and precise because all the decisions are taken based on dialogue only.

Takeaways

So, let’s sum it all up. We have shared our thoughts and insights regarding the development process estimation, based on our experience. We do hope Agile teams will find them useful, regardless of the framework. If you are a product owner, this article will be in hand for you as well. The estimates can make the budget and time frame clearer and more understandable, as well as determine the scope.

Still have any questions regarding the estimations? Drop us a line and we will get in touch shortly.

We do hope that you can create perfect estimates for your ongoing and future projects. In case you face any difficulties, keep in mind that you can get a free estimate from our team within 24 hours. So do not hesitate to hit the button below and drop us a line!