Developing a system is a project full of details, and estimating its size before making a proposal or starting its development is essential. An error in understanding the amount of work required in a project or its duration can mean failure, causing stress and even financial losses.

What is the cost to develop the app? How many days or months are required from each professional on the team? How much do I need to know about each task to arrive at a realistic estimate?

As these are recurring questions in the consultations we conduct, I wrote this post with an overview of what we have learned over the last 20 years developing systems of all types.

Additionally, I will recommend that you download our software project estimation spreadsheet, to help you get the numbers you are looking for.

Information gathering cycles

Normally, everything starts with a meeting with the client to understand the project and the demand. It is important to know that it will not be possible to understand 100% of the project and obtain all the information in a single meeting. Perhaps in this first meeting, it is important to understand the overall scope of the project, the main processes and interactions, the expectations regarding the interface, usability, and applicability of the solution.

Everything that is important, note it down simply. If a major doubt arises, note it down to ask later, but don't expect to learn everything now, focus on the essentials. A great tip is to use the Meet Transcript plugin for Chrome, which will record the entire conversation of the meeting (if it happens within the browser, like in Google Meet or Zoom on the web) and save it in a document on Google Drive. It's rare that I don't have to go back to the meeting transcript to find some information, when I don't remember if something was said one way or another.

After the meeting, it's time to start an estimation spreadsheet, where each resource spoken in the meeting should be converted into tasks and then measured. Here, I already make it clear that it is very difficult to estimate a larger project without a spreadsheet, without focusing on the tasks, without calculating.

A few cycles of information gathering will be necessary, as what is sought in the estimation is clarity. In the end, we will have the approximate "amount" that represents the project, be it in hours, days, people, or any other resource.

Features, stories, and tasks

A feature is a system feature, it's something that our client wants in their system. A practical example is when the client says "The user must authenticate in the system". In agile methodologies, you may hear this as a story, which will tell us how the user should access the system, and follow a flow to access it.

A resource like this will be divided into various smaller tasks, done by various people. It is necessary to create the design for this interface, it is necessary a database for storage and reading of the data, it is necessary a backend that accesses this information, and finally, an interface where the user will effectively enter their data to access the system.

Each of these smaller tasks will need to have a time in hours, to compose the total time of this feature.

While something is not clear, send questions by email or meet again if necessary, until all unknowns are clear.

An advantage of having a spreadsheet with all the details is being able to attach this detailed task list to the contract, to avoid scope changes during development.

Following this post, you will see how to maximize your chances of success.

How to find the task time?

How long would it take to implement a responsive email and password login interface, with calls to the backend, error handling, and user feedback?

If you don't know the answer yet, there are more challenges to be overcome. We will explore here two possible paths.

I always recommend having a technical person along, if possible even the development team, because it's very complicated later on to say "you will implement this task in 3 hours" and the developer responds “I can only do that in 9 hours.”

Starting from the smallest implementable portion, and continue multiplying

Imagine measuring the time it takes to read a page of a book, then, given the number of pages, knowing how long it takes to read the book.

An effective way to think about the time of a task is to imagine a very small task, which you can say with certainty "the effort to implement A is one hour." From there, every task would be compared to this smallest. "Implementing B would take twice the effort of A", "C, on the other hand, is twice as big as B."

In this approach, it is even more recommended to have your development team thinking together.

Measuring and recording real time

Having historical information is undoubtedly the best way of all, to be sure of how long an average dev of your team takes to do it. The way I recommend doing this is using a time tracking system, such as Hubstaff, doTeam or Clockify, where the developer must play on each issue, following a title pattern to make it easy to find the times later, such as "Issue + Category + Title", for example:

#33 - Backend - Send welcome email

With some precise measurements, you begin to understand the time of things. The sooner you start measuring the working time, the sooner you will have more accurate estimates in future projects. As a bonus, you will notice that some developers take much longer to do some tasks than others, but that is a topic for another post.

Hidden Precedences and Dependencies

This is what the clients said, what he expects:

Send a welcome email to the user

This is a relatively simple task, I would say it involves about 3 hours of backend work only. It's just sending an email, done. 3 hours is definitely enough, agree?

What I'm going to explore in this topic, is how a harmless resource ⚠️ can become giant and complex, going from 3 to 50 hours easily, meaning, it can take 15 times longer.

As for the email sending, will it be a simple text email or will it have a basic HTML template (that all emails could have)? If HTML is needed, I would add 3 hours for the front to create a basic theme.

Hold on, to send an email, it's necessary to have already configured in the project a library for sending emails. Will it be a "pure" email or will it use some service like AWS SES or Sendgrid? All email sending will depend on this initial task. If it's a pure sending, to implement and test well, I would consider 6 hours, if using an external service, about 10 hours.

Now, observe the following three topics, which are very technical. For each of these three technical levels of perception, this task could be increased in hours.

Going deep into technical details

If there will be HTML, of course, it will have the system logo on this template. Where will the image be? Because the complete URL of this image will be necessary, which I would say, it will be in a backend assets folder. When sending the email, the backend will need to know this URL, or at least the base URL of all assets.

I would add another 3 hours to the backend.

Going deeper, with more technical details

If we are going to send an email to the user, it's good that he can have an option "I don't want to receive these emails anymore", and make an unsubscribe. This would imply a new route in the backend to give an update to the user, disabling email sending, as well as updating the sending method, so that it never sends anything to a user who opted out.

I would add 5 hours of backend for this

So deep, that only with practice can you go

If email sending is crucial for your project, some additional aspects can be considered.

The first one is to know if the email was delivered. Understand that there is a big difference in sending successfully and reaching there. For the system to be sure that the destination server accepted and received the email, using SES or another service, I would consider another 18 hours of implementation, because it will be necessary to implement a webhook, which will receive after a few seconds of sending the information if the email reached the destination server.

Reaching the server is not the same as appearing in the inbox. The server can look at the email and say "It's spam!"

The second aspect is to check if the email has the potential to reach the inbox, using some tool or service that receives the sent email, and checks in it the indications that would make it not reach the inbox. A tool that I recommend is mail tester, which is free and highly effective. However, to test the email and make the possible adjustments, which will range from the content of the text, HTML code, and even domain DNS configuration, I would add between 6 and 16 hours to the task.

Perhaps realizing the risk in a task, is one of the most difficult parts of an estimate, because it requires practice in the task in question, perhaps having already done something similar and knowing all the traps that may exist.

Some tasks hide a great risk, such as integrating with a third-party system. Seeing examples of integration can seem very simple, looking at the documentation can seem simple, but when you start developing you realize that the documentation did not make it clear that some headers should be sent, that some token expires every few minutes, that the real data is returned in a different way, or even that the process of trying the integration in the development environment is time-consuming.

How to charge for the project's risks

When using a range of hours to reflect risk, your project will not only have one total size, it will have two. This means that the project as a whole will be done between 815 and 970 hours, and it is a good way to reflect the reality of software development.

If you rely on the 815 hours and charge the project based on them, you are pulling all the risk onto yourself; if you are delayed in any aspect, the loss will be yours. If you charge 970 hours, if the activities are "lucky" and do not take as long, you will have a profit on the risk, which is also strange. The final value may be very high.

An alternative is to reach an amount between 815 and 970, perhaps the average, it is not scientific, but it is not only with you or the client the risk.

Another way is to charge the minimum, but make it clear in the contract that tasks with risk will be measured and charged individually if they exceed the estimated.

What cannot be done is to ignore the risk, thinking that all tasks will happen smoothly, that is an illusion.

When the estimation goes wrong

Normally, we don't like to talk about things when they go wrong, but as I hear many of these stories, I think it's valuable to bring this experience to you in order to help you avoid them. 

The customer has already said what they wanted, and if the deadline is exceeded and you suggest delivering less, the customer will be furious. They will not accept anything less than what was agreed upon. 

Then the magnificent idea arises to charge more for the additional hours that would be required, and again, the customer will not pay anything beyond the amount that was in the contract and may say that "the mistake is yours". 

Errors in estimates always fall back on looking at the contract, which generates tremendous discomfort. It's a situation that nobody wants to have to deal with. That's why dedicating time and effort to estimate is more professional and avoids conflicts later on.

Remember the project's bootstrap

In the early days of the project, there will be a lot of tasks to be done that are not related to the features that will be developed. Some examples:

• Discussing technologies, libraries, and project architecture 
• Creating repositories, folders, giving access permissions 
• Creating base design for the project 
• Creating base of the backend project 
• Creating base of the frontend project 
• Configuring code quality tools 
• Documenting project standards and setup for the team 
• Creating base CI/CD for the project

These activities alone usually take between 100 and 200 hours with us here

Sending, delivering, collecting feedback

Depending on the type of project, publishing a version for delivery can take some time, varying from the technologies that were used, the environment in which it will be executed and the level of maturity in CI/CD of the team. Take this time into consideration.

Immediately afterwards, it is necessary to notify the client what is being delivered, possibly providing a step-by-step guide so that they can try out all the new features, and then receive feedback.

In "optimistic estimates," a person thinks that the days will happen completely in sequence, one after the other, but at some moments, it is necessary to stop everything, wait for the client to try, validate, approve, before moving on. I recommend having a maximum deadline for these stages in the contract, otherwise, the client may relax and take days or weeks to give feedback.

After obtaining feedback, more time may be needed for adjustments as well as bug fixes.

Knowing the time that recurring tasks take to be implemented

The most assertive step to have a more accurate estimate is to measure the time your team has taken on tasks, so you can consult these numbers and adopt real hours for your estimates, as I have already said.

But some essential tasks should have their time known as soon as possible, those things that all projects will have, for example:

• A complete CRUD (listing, inclusion, alteration and deletion of records), counting both the time of analysis, database modeling, backend, frontend, and tests
• A simple authentication (email and password)
• An authentication using social networks
• A user profile with photo, textual information and data obtained dynamically, with the option to change (including photo upload)
• A dashboard full of data and graphics
• Obtaining permission for notifications, storage of the token, implementation of sending, receiving, displaying and deep link to the final destination

It depends on the type of project you develop, but try to observe these blocks to understand them.

In conclusion

I hope this post has helped you understand a little more about how to make an estimate, taking into account details that may have gone unnoticed, making your result more assertive.

Be sure to download our estimation spreadsheet to better understand your projects, and contact us if you need any extra help. It will be a pleasure to assist you.