Subscribe to our newsletter
Stay up to date with our latest news and products
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.
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.
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.
Finding the time in hours may not be so simple, but without looking at the actual time that each thing will take, we will not be able to arrive at a total project time. I will talk about this further below.
In the first meeting, the client tells us:
The event will have suppliers, exhibitors, and sponsors
In this sentence, we see that we have 3 or 4 entities: event, supplier, exhibitor, and maybe the sponsor (which may be just a relationship, maybe). Assuming that I already understood the first three, I need to know how this sponsorship thing works.
A trap is to think "this must be a simple thing" and imagine the easiest way, underestimating the activity. It is also a mistake to imagine that it is something super complex and elaborate, overestimating what needs to be done.
The correct thing is to note any and all doubts that arise during the estimate, so that at the end of the first pass through the spreadsheet, they can be sent to the client. What we want is to get the details of the features and understand in detail what is expected. Most of the time, the client themselves did not stop to think about the questions that will arise, and will end up thinking and deciding when asked.
Don't take the risk of accepting a proposal in a hurry to close the deal, without a truly clear vision of the project size. Simplifying, we can see the estimation process as in the diagram below.
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 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.”
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.
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.
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.
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.
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
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.
There are some ways to calculate the risk, but, simplifying it can be like this; what is the chance that this task has some hidden detail, that may cause some problem in the development, and exceed the time? I will list three activities, and you tell me which is the risk of exceeding the time; if it's low, medium or high.
Validating the event before publishing, is simple and it seems to me that in 6 hours is feasible, there is not much chance of error, it would be a low risk.
Deleting the account has some chance of causing problems, since deleting records in the system can make something essential disappear, or the database relationships may have their delete actions (such as "delete cascade") incorrect, so it is a medium risk.
Sending backup to servers configured in 16 hours, has a higher possibility of causing problems, since one server would be an S3, another an FTP (the old ones), another SFTP.. in theory it seems easy and can happen to be done in 16 hours, but if something goes wrong, the dev can spend three or four more days just debugging, which makes this task high risk.
In the calculation itself, what would happen with the 16-hour task, is that it would become a range going from 16 to 32 hours, in the same way the deletion of the account would go from 8 to 12 hours.
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.
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.
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.
These activities alone usually take between 100 and 200 hours with us here
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.
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:
It depends on the type of project you develop, but try to observe these blocks to understand them.
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.
Dedicated software development leader with 20 years of experience in dealing with dozens of projects in diverse industries, Tiago has acquired throughout his career great knowledge in solving problems using the right technologies and has developed tremendous technical skills in many platforms.
How about enjoying the Web Summit Rio side events, participating in groups, connecting with interesting peers, and even discovering stunning spots?
We compiled an objective list of the current side events and groups, so you can get much more of your days in the wonderful city.
In large teams, or teams with a high volume of tools, knowledge management has always been a complex activity due to the constant changes in technology and turnover of team members. In a development company with a dozen people, considering languages, frameworks, libraries, tools, methodologies and paradigms, we are already talking about more than 200 pieces of knowledge.
Continuous Integration and Continuous Delivery is the automation of the building, testing and deployment processes. These practices have proven to make coding more efficient. Learn more about it here.
Stay up to date with our latest news and products