When it comes to software development, the question that many clients tend to ask right away “How much will my solution development cost?” Unfortunately, software development is a service, not a product, and you can’t give a price tag instantly. And although it is possible to provide some kind of its estimation, it is not as easy as it seems.
You may think that this is an easy equation in which time = money. So if you define time needed for the development, you’ll get the price you need to pay. But, unfortunately it’s hard to estimate the exact time needed to complete something as big as software, especially if it is a business intelligence tool. This means that the specialist should sit down and write a huge list of tasks, TO-DOs, risks, required tech takes and time needed for them to complete the development. So as you can imagine some major miscalculations are possible.
That’s why when someone gives you a quote immediately or claims that it has 90% accuracy and there will be no major price changes, don’t buy it!
Estimation is a complex process. Moreover, final accuracy of the quote is largely dependent on you and how well you understand the development goal and objectives. Therefore in this article we would like to discuss the estimation topic in detail. We will explain how the projects are estimated, what factors are taken into account and how we perform estimation in our company.
Inputs required for Estimation
There are several basic ingredients required to complete any kind of estimation. They are the overall scope of work, story points, development risks, and technology stack. The accuracy of any quote depends greatly on them, so to understand what each of those components imply, let’s take a closer look at them.
Scope of work
This is a 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 project plan. The stage on which everything is performed is called the Discovery. It helps to discover all the unknowns, formulate high-level project description and requirements, plan the development itself and write 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 depends on our mutual efforts. Your input on this stage is irreplaceable and it influences the accuracy of the quote.
But do not worry, as we won’t ask anything that goes beyond your competence. We’ll help you to crystallize the idea without getting into technological 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 expectation you put on it.
So what we may ask you about is some basic use cases you may need, the functions and features you require and the list of currently used solutions (if there are any).
Upon getting those answers we’ll make work breakdown structure, which divides the project into separate tasks.
E.g. You Project = Function A + Function B + Feature C (module 1 + module 2).
The more detail 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 Estimation from the very beginning. Which 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.
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 during 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 the most of the risks are solved during 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 an extensive experience in building solutions for your particular business niche, then the chances are that you’ll face less risks on your way to app release.
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 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 middle one will cost you less than the work of senior. But the selection of the specialists depends on your project complexity and feature set that should be incorporated. Sometimes the job can be done only by the professionals of the high level.
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 it is not really true. Let’s speak about some interesting cases to understand how everything really works.
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 experience of the developers. You probably heard of junior/ middle/ senior qualifications of programmers by their experience level. But this grading system is too rough to give accurate assumption about time. The error chance can be up to 50%.
For example, one middle-leveled programmer may require 5 hours and another one 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’s 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 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 solutions 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 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. A man with unique brains, 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 works by 50%, you should get ready for ~70% budget rise.
To back up or not to back up middles?
Luckily, there is a way to help middle developers if you hired ones and now struggle to speed up the development process. That’s exactly why you sometimes need to add a Team Lead or Senior Developer in addition to Project Manager. Senior Developer is a problem solver who is meant to mitigate risks and help middles with the most difficult tasks.
Team Leader is like a curator, who increases the productivity of less experienced programmers.
One middle developer will battle task 1,5 times faster if he will be backed up by the senior programmer. This way we can decrease development time without extreme rise in development costs. Because you’ll pay only for 3-4 hours of “senior backup” instead of hiring him full-time.
How many senior back up 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 the information about companies’ values, approach to work and many more, you may notice 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. So we offer you to take a look at the three most popular estimation approaches together and to compare their pros and cons.
This is an abstract type of estimation that is suitable for Agile methodology. In general it describes the complexity of work, its overall scope, and touches the elements of project backlog. Story points are used when you do not have a fixed budget and strict deadlines, but there are high-level project requirements. So the estimation is not detailed but rather an abstract.
Story point itself is the smallest abstract index describing efforts needed to complete the set task. Here are some parameters that are included in this type of estimation:
- The amount of workforce needed to complete the task (it depends on how big the users stories are and how long it may take to complete the necessary job according to them);
- The complexity of the work (how hard it will be to complete the task);
- The risks and uncertainties that can influence the development according to user stories;
- The knowledge of the team members (how much they know and how helpful that info is for the development).
If you estimate every element of backlog in story points, then you will be able to get overall project size. And here is the formula that will let you get a project timeframe:
Overall project size ÷ speed of team work = project development time
Based on the time you get you can set deadlines, define scope of work per certain period and create a precise schedule. It seems like an easy and effective method, but yet it has its disadvantages.
- The team often tends to overestimate required working hours;
- The accuracy of the estimation is questionable and team may not understand the story points criteria;
- Project velocity depends on knowledge and expertise of all team members. So any changes in team or replacement of the specialist will have its consequences influencing the speed.;
- You will not know the exact development terms.
This approach is perfect when we have well-defined backlog, know all project details and are obliged to complete the job within a certain time frame. For the client everything is clear and transparent. And the development company from its side should show the necessary development term in days and time that can be estimated and paid for.
And now as to the real numbers, for example, well qualified software engineer can work effectively 5-6 hours per day. So if a software engineer states that a certain task will take him up to 8 hours, we should understand that his effective work will take around 75%. So while defining his Capacity per Day we should re-estimate the task that should have taken 8 hours and set 10 hours for it.
Although such estimation approach is better than Story Points, it offers more exact dates and terms, it has its major cons as well:
- The team members tend to underestimate the number of required working hours because thy take “Sunny day scenario”;
- Only the person who is going to perform the task can provide a real estimation;
- It requires a high competence and expertise level of the whole team;
- You need to understand all requirements and and software architecture should be high-class.
An accurate estimate helps everyone. It helps stakeholders to have a confidence in their project. It helps a vendor partner to manage its own team. It gives our team members a reasonable development schedule, so they could work without a rush and deliver without loss in quality. And, of course, accurate quote reassures that you will get your product within a set budget and time.