Table of Contents
When it comes to software development, the question that many clients tend to ask right away is: “How much will my solution development cost?” Software development is a service, not a product, and you can’t give an accurate price tag instantly. And although it’s possible to provide some kind of estimation, it isn’t as easy as it seems.
You may think that this is an easy equation in which time = money, where time is multiplied by some rate factor to come to a total. So if you define the amount of time needed for the development, you’ll get the price you will need to pay. But unfortunately, it’s impossible to name immediately the number of hours required to develop something as big as a software solution, especially if it’s a business intelligence tool. The specialist should sit down and write a huge list of tasks, TO-DOs, possible risks, required tech takes and time needed for them to complete the development. So as you can imagine, some major miscalculations are possible as there are many moving factors at play.
That’s why when someone gives you a quote immediately or claims that it has 90% accuracy and guarantees that there will be no major price changes or deviations, don’t buy it!
Software cost estimation is a complex process. Moreover, the final accuracy of the quote is largely dependent on you and how well you understand the goals and objectives that you are looking to solve with the new tool, whatever it may be. Therefore, in this article, we would like to discuss the estimation topic in detail. We will explain how the project outlays are estimated, what factors are taken into account, and what logic we apply here at our company Altamira to perform cost estimation as best we can.
Why does estimation matter?
At first sight, the estimation may look unnecessary and inadequate: why do we need to spend time and resources on the process that isn’t developing? Why can’t we just hire a few developers and dive straight into coding?
Software projects, whether it’s a mobile or web app, are complicated. They have dozens of features for implementation, there are mandatory policies, compliances and protocols, and of course, you need to make sure that your software is functioning properly and there is no risk of crashing. It is impossible to navigate through such a huge amount of workload without a plan, or otherwise, you may lose your path in the heat of the moment.
On the other hand, estimating will take some time, but it won’t be wasted in vain. A thorough estimation guarantees that a developing team and stakeholders will understand what needs to be done, how much effort it demands and what the remuneration should be. Estimation is directly related and connected to planning and managing the future workflow, while also specifying the software development cost.
So, to put it simply, estimation creates a roadmap of your development and defines how long it will take to get from point A to point B and then to point C and how many resources we need to spend for a successful trip.
Inputs required for Estimation
There are several basic ingredients required to complete any kind of software cost estimation. They are the overall scope of work, story points, development risks, and technology stack. The accuracy of any quote depends greatly on those points, so to understand what each of those components implies, let’s take a closer look at them.
Scope of work
This is the first and foremost factor influencing every software development estimation. Here is how everything starts — you contact us, share your app idea, and together we shape it into a concrete project plan. The development stage where all of the above fits into is called the Discovery stage. It helps to discover all of the unknowns, formulate high-level project descriptions and requirements, plan the development itself and write the specifications document.
No one knows your business better than you do, that is why the result of the Discovery stage and determination of the scope of work hinges on mutual and concerted efforts and cooperation between all parties involved. Your input as the business owner or manager into this stage is indispensable, and it has a direct bearing on the accuracy of the quote.
But do not worry, as we won’t ask anything that goes beyond your competency. We’ll help you to crystallize the idea without getting lost in the technical debris. We have Personal Client Managers, Business Analysts, and Software Architects for figuring out everything related to the tech side of your project. They will tweak and adapt your idea to technological standards and industry requirements. So your main task is to let us know your idea, the challenges you would like to resolve with the software, and the expectations that you place in it.
So what we may ask you are some questions aimed at determining some basic use cases that you may need the software for are, the functions and features you require, and the list of currently used solutions (if there are any).
Upon getting those answers we’ll make a work breakdown structure, which divides the project into separate tasks.
E.g. (to help visualize): Your Project = Function A + Function B + Feature C (module 1 + module 2).
The more details we can get, the better estimate we provide. On average, we have three detail levels, depending on the amount of information provided by the client:
Keep in mind that small projects or those with detailed inputs and design allow us to provide Detailed Estimations from the very beginning. This is very advantageous and lets us proceed to the development itself a bit faster, and this, in turn, reduces your time to market and overall development time.
Development Risks
Risk is a general naming for all assumptions and constraints that may or may not affect the project. As we proceed from stage to stage, those assumptions convert into details, and constraints are solved.
There are two kinds of risks we account for during software development estimation: internal, and external. Let’s describe them in detail so that you can get a clear understanding of each kind.
At the end of the day, you should not be worried because most of the risks are solved during the specification stage by our Software Architect and Business Analysts. This work is included in specifications price, as well as the search for suitable technologies. Also, if you choose a team that has extensive experience in building solutions for your particular business niche, then the chances are that you’ll face fewer risks on your way to app release.
Tech stack
Each tool has its purpose. Some tools are better suited for solving specific problems. Some technologies require more expensive specialists. That’s the reason why one technology stack can be cheaper than another. Frameworks, for instance, can save you a lot of time coding. Ready-made code solution does this trick too.
In most cases, the decision of whether to choose certain technologies is made by the development team. All you need to define is tech stack, programming language and specify if there are any must-have integrations. After you’ve done it the team will do its job. Business Analysts will let you know how many tech takes and of what specialty will be required, the number of development hours each specialist will need to complete your app, and the hourly rate of each programmer, etc. The hourly rate depends on the qualification of the developer.
For example, the work of a mid-level specialist will cost you less than the work of a senior software engineer. But the selection of the specialists depends on your project’s complexity and feature set that should be incorporated. Sometimes the job can be done only by the professionals of the highest level, but sometimes hard-working juniors are a good fit.
Software Development Effort Estimation
Talking about efforts we need to answer three questions:
- How long each task is going to take?
- Who do we need to deliver each task?
- How much will it cost?
So as you’ve probably understood from those questions – it’s all about Time, People, and Money. Some people tend to think that if you hire more developers but of less qualification, then you’ll get your project done faster. But that is not necessarily the case. Let’s speak about some interesting cases to understand how everything really works.
The system we use to grade developers
The hardest question to provide an answer to is: “How much time will it take to build my app?” That’s where you go for the experience of the developers. You probably heard of junior/ middle/senior qualifications of programmers, sorting them by their experience levels. But this grading system is too rough to give an accurate assumption about time. The chance of error is up to 50%.
For example, one mid-level programmer may get a certain task done in 5 hours, whereas another mid-level programmed may require a full 10 hours to complete the exact same task. Of course, you can make time limits and force people to stick to them. But this leads to the loss of quality, and you definitely do not need that.
That’s why we use our own qualification system for developer skills assessment. It’s based on:
- historical performance data,
- types of projects he has worked on,
- his overall skill set and expertise,
- regular proficiency tests.
Thus, depending on a developer’s grade, we can say more accurately how fast can the certain task be solved without any loss in quality. That is why on the stage when we write specifications and select tech stack, we think about the developers. We carefully select who would do the job, take into account their average productivity rate to get the most accurate estimation, and calculate how many hours they may spend developing your particular solution.
How we estimate the time
Once we’ve got all the required project ingredients like tech stack, necessary developers, list of involved specialists, well-written specifications document, our Software Architect and Business Analyst can estimate the time required for your solution’s development. This task is performed by using several approaches:
Should you hire a second developer?
There is a joke between Project Managers: two women won’t make you a baby in 4.5 months. Meaning no matter how hard you want it, you won’t speed up a project by 50% by adding one more developer.
Based on our experience we can state that one extra developer on the task gives no more than a 30% speed boost. Yes, that’s better than nothing, but it is definitely not what you expect from such a “team extension“.
You may be wondering why exactly it is how it is. Well, to start, one needs to understand that we do not clone people but put a new individual. Each person has a unique brain, coding, and problem-solving approach and skills. Add to this the simple fact that you can’t put two pairs of hands on one keyboard and the answer is clear.
Putting a second developer means dividing tasks on the project between several team members. But development pace won’t become faster inside a single task. That’s why the budget often increases disproportionately to the number of specialists added to the project. If you want to speed up development progress by 50%, you should get ready for a ~70% software cost rise.
To back up or not to back up middles?
Luckily, there is a way to help mid-level developers if you hired such professionals and are now struggling to speed up the development process. That’s exactly why you sometimes need to add a Team Lead or Senior Developer in addition to a Project Manager. Senior Developers are problem-solvers who are meant to mitigate risks and help middles with the most difficult tasks.
A Team Leader is like a curator, who increases the productivity of less experienced programmers.
One middle developer will overcome a task 1.5 times faster if he will be backed up by a senior programmer. This way we can decrease development time without an extreme rise in development costs. Because you’ll pay only for 3-4 hours of “senior backup” instead of hiring him or her full-time.
How many senior backup hours will your project need? That’s where we need to define software risks, internal and external. The amount of time directly correlates to risks and uncertainties your project has. Most of these risks will be solved by Software Architects at the project planning stage. They will find software solutions, third-party modules, and code samples that are familiar to lower specialists, thus decreasing the need for senior programmers.
Some popular approaches to estimation
While searching for your development partner and collecting information about companies’ values, approach to work, and much more, you may have noticed that the approaches to estimation will differ as well. This happens because companies can use different project management methodologies, handle the tasks and time frames differently, and be more open to emerging trends.
There are three main elements in development: time, scope, and cost. We established that unfortunately, it’s impossible to keep all three fixed due to the complexity of software development. The two basic philosophies allow varying different factors, and it impacts the whole approach. Let us introduce you to the different software cost estimation techniques.
Traditional approach
The traditional approach is based on the stability of your scope, and thus will give you the maximum efficiency if the scope is determined and, moreover, it won’t change till the end of the project. The metric used here is called man-hours. Each task is estimated considering how much time it will take to complete it.
Only the actual time working is counted, for example, if the task was in progress for two days, but the developers spend one hour working the first day and one hour the next, it will be counted as two hours.
Using man-hours estimation, it’s easier to define the whole budget of the project: you just convert all the tasks into hours and set the rate for the man-hour. Moreover, you also get a time evaluation on how long the project will take.
However, this approach is considered outdated and old-fashioned by the majority of the IT community. Software development is a long-term process where you can’t predict everything, as we’ve already described earlier. The changes are possible, some features might be eliminated or switched to the higher or lower priority.
Another issue lies in evaluating the task. Different developers might take different amounts of time to complete the same task for example: a senior will do it in 2 hours, while a junior might need double the amount of time to match the senior. Of course, you can ask the developer who is in charge of the task to estimate it, but life is life — there are sick leaves, vacations, accidents, and the task may be reassigned to another person. In this case, your time evaluation loses accuracy.
Coding is resourceful work, and it’s unlikely for developers to work at a maximum capacity of 8 hours every day.
So if a software engineer states that a certain task will take him up to 8 hours, we should understand that he or she will be at their best, producing the most effective work output some 75% of the time. So while defining his or her “capacity per day”, we should re-estimate the task that should have taken 8 hours and set 10 hours to accommodate the aforementioned nuance.
To avoid discrepancy between scheduled and actual man-hours, a lot of teams use padding to make their estimate precise. But an additional safety cushion of 25% for the task may bring more harm than benefit to the cause: by adding some amount of time to every task, your project may become or seem like a large and scary mechanism.
Parkinson’s law is another thread for man-hours. It goes like this: work expands so as to fill the time available for its completion. So what happens when the task is estimated for 8 or even 10 hours when the actual developer can in reality complete it in 4 hours only? The efficiency decreases and becomes stretched in time when it can be done far more swiftly. This approach, like any other, has its own set of perks and downsides. Let’s sum it up.
Pros and cons of the traditional approach:
- clear and understandable system for developing team and stakeholders involved;
- good fit for the project with an established backlog;
- easy to follow the plan and check your progress of work.
- hard to determine the actual time of the task;
- teams tend to estimate basing on Sunny Day scenario, the perfect conditions with 100% efficiency and no obstacles;
- no place for flexibility or changes.
Agile approach
Agile is a philosophy of software engineering which values flexibility. Instead of demonstrating and releasing the product when the development is finished, Agile suggests breaking your workload into short stints, or sprints, and creating MVP, or minimum valuable product — functioning software with a minimal amount of features, but ready to be run by users.
Agile is value-driven, not plan-driven like the traditional approach, meaning that the added value of any feature you want to implement is more important than following a step-by-step plan. Agile is also a process of constant learning, growth and adaptation: the result the team gets in one sprint helps to re-evaluate the next.
While Agile allows you to adapt your scope, the time and cost stay stable. Usually, the amount of features is divided into fixed packages, each of them has its own price. The customer can choose what packages are needed and what packages can be dismissed. And vice versa: if the customers want to add new features or adapt the software to another platform, just a few sprints will need to be added.
As we mentioned, Agile is all about flexibility, so changes may be implemented easily. Embracing this approach at the beginning, the team isn’t as rigid on what the final version of the software has to look like or be, that’s why introducing changes isn’t painful. The client just needs to provide feedback, and the changes will appear in the next interactions without additional cost if the modifications are equal.
With every sprint, your software becomes more advanced, and if it reaches the level you initially wanted or expected, you can easily terminate the project and get a fully developed application. It’s possible in a stable relationship between the developers and the customer that is based on trust and understanding, which is easily achieved through Agile methodology.
There are then several techniques for Agile project estimation, for example, Planning Poker or Wall Estimation, and we will talk about them further later. But a lot of them are based on creating an abstract metric to measure the difficulty of a task.
Wild card: No estimation approach
While we root for estimating the cost of every software development project, we had to also mention this alternative approach. It’s useful when the effort to estimate the costs isn’t worth it. Lean principles, which are the basis of the no estimation approach, focus on maximizing customer value while reducing unnecessary actions as much as possible.
But it doesn’t mean that there is no measurement for the workload or the efficiency. And for this goal, the new glossary is displayed as Work in Progress (WIP) and Idle Time (the time of delay on each stage). However, this system is suitable when the software is already in use and requires quick, small changes.
Techniques of Agile estimation
Every project can benefit from different approaches, making the best selection decision depends on the conditions, limits, and goals. But our usual, default choice is the Agile techniques, as they proved to be efficient through the years of our experience. It helps us to stay flexible and reach the maximum result even if we are bombarded with changes or riddled with obstacles.
There are different ways to estimate the workload, and while evaluating the difficulty and time, Agile also requires evaluating the priority of the task. Here are some of the best techniques known in the Agile practices. Apart from their performance, they also bring a lot of fun and creativity to the process.
Story Points
Story point is a unit to evaluate your task. The user story is referred to be a feature you need to implement, but seen from the user’s point of view. Story point gives it a measure of the story’s size and difficulty.
It’s an abstract metric, which is based on the developer’s perception because story points are always rewarded by the whole team. While implementing story points, firstly, you need to choose the comparison points — what you will consider small and what is going to be giant. Mitch Lacey, the owner of Mitch Lacey & Associates, Inc, suggests marking your small task as two points in case you will need to work with an even smaller story.
To create a certain range of story points value, you may base Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21, etc.; every following number is a sum of the previous two. You can continue to give points as far as you want, but it might be efficient to set the limit, for example, 21. Any story received more than 21 should be split into several smaller ones.
Story point isn’t equal to hours, otherwise, it may become a man-hour estimation once again. The stories with the same points may vary in hours of completion, as well as the point value of one team will be different from the other.
Planning Poker
Planning Poker is an exercise to grant story points and estimate the size of the stories available in your backlog. The key to the successful estimation is the engagement of the whole team working on the project. Such a wide view will provide relative information. Of course, the first time may have a lot of uncertainties — for all that story points are an abstraction created for a certain project — but when the team gets used to this, the estimation becomes quicker and easier.
How does the process work? Before starting, you need to do homework and prepare cards with story points. When the story is chosen, the team discusses what it implies and comes to a common vision. Every team member independently chooses a card with the value, and when the decision is made, everyone presents their number simultaneously. Everyone needs to reach a common agreement and set a value, otherwise, it may lead to conflict and the integrity of the exercise will be ruined.
Planning Poker helps to evaluate and compare the backlog of the whole project but it can also be used for evaluating sprints: the number of the cards becomes hours required for a certain story.
Wall Estimation
Planning Poker is good for a project with a few stories, but what if your software has 100-200 stories? Estimating them through Planning Poker will take an eternity.
In this case, you might opt for another technique instead — Wall Estimation. You need two things: all your stories printed on cards on a big wall. The team will determine the value of the stories without any unit of measure, but compare them with each other. The stories placed higher have greater priority, the ones that could be postponed placed lower. The width of the wall affects the size of the story — the right side is for the biggest stories, the left is reserved for the smallest. It’s a good idea for the client to join the estimation to determine the priority of the stories, while the team is in charge of evaluating the size.
T-shirt sizes
It’s another way to abstractly estimate user stories, but without the help of numbers. Instead of points, you value your stories in T-shirt sizes: S, M, L, and XL. A rather small task is S, while XL is connected to an extra-large story.
It’s a great technique for newcomers in Agile to get used to abstract evaluation. If you strongly associate story points with hours, you should switch to T-shirts or any other metric you are comfortable with comparing/associating: different breeds of dogs, for example. Also, it’s quicker than Planning Poker, because there is a narrower rating scale.
How do we estimate projects?
If you are in the earlier stages of your project and don’t know how to conduct it further, don’t worry — we offer the Discovery Phase. We mentioned it before while talking about the estimation of the scope. But Discovery is also meant to guide you through the market research, possible risks, and determining the tech stack. Our Business Analysts, Product Managers, and Software Architects will sharpen your idea into detailed visualization with:
- Project Vision Documentation;
- Tech Vision;
- Specifications;
- Roadmap;
- Design Concept.
When we get to the next stage, the actual estimation we were talking about, we provide you with the document containing the breakdown of all user stories, testings and code reviews required for your software. We are following Agile methodology and estimating projects depending on their scope and hours required for their completion. We also consider third-party integrations which may affect the final cost of the software. Therefore, normally estimated and real budgets match, and it’s a very rare occasion when the final cost exceeds the prior estimation.
If you want to see how it looks like, click here and download the estimation sample for the CCTV Camera software.
Bottom Line
An accurate estimate helps everyone. It helps stakeholders to have confidence in their project and understand the software development cost. It helps a vendor partner to manage its own team. It gives our team members a reasonable development schedule, so they could work without having to rush, ensuring reasonable delivery without loss in quality. And, of course, an accurate quote reaffirms that you will get your product within a set budget and given timeframe.
