Estimating software development time can be daunting, but there are a few tricks that can help you get accurate numbers.
I remember the first time I was asked to rate …
Then it was taken by surprise.
I was taken to the office where my boss, his boss and someone from the senior management were, and we sat at a round table, staring at each other.
The analysts read out some of the client’s demands. We discussed them briefly.
And then my boss turned to me and asked: “How long will it take?”
I didn’t know what to say – I was not prepared for this. I was not told that this meeting would need to be assessed – I thought I was invited to attend so that I could learn something.
And suddenly everyone was looking at me and waiting for an answer, but I was at a loss and did not know what to say.
There was note paper in front of me. I took one piece of paper and began to write some numbers – no idea for what, but definitely not for this assessment.
After about a minute, which seemed to me like an hour, I decided to just say the first thing that came to my mind: “I don’t know … 600 hours?”
The boss laughed and then told the others to count on about 1,200 hours.
I don’t really like to remember that day.
It is clear that I still had a lot to learn, but I was tormented by one question: how to assess the amount of work to be done?
Purpose of the assessment
Before you start evaluating, you need to understand what it will be used for. You tell the numbers to your boss or higher management – and what happens next?
Scope assessment is used mainly for two purposes:
Billing the client.
Senior managers, directors and vice presidents of the company have a stake in ensuring that work goes and gets done on time. They need to know what will be done and by what time – and this requires an estimate of how long it will take for the project.
They know how much work which development team can take on in a month, quarter, and year. And in order to keep employees busy, management needs to draw up a timetable for working on projects. The estimate you have given will help in this planning of the download.
Let’s say you have three people on your development team. Each one works 40 hours a week – that’s about 160 hours a month, or 480 hours a quarter (for three – about 1500 hours).
Imagine that your team has to complete five projects – with an estimated scope of work of 800, 400, 300, 200, and 50 hours. As you schedule your load, you will see that you will not be able to complete all projects by the end of the quarter. Managers will create a schedule using a certain percentage of maximum utilization in case development takes longer than anticipated.
With the estimates from our example, it would be possible to tackle projects for 800, 400 and 50 hours, and at the same time there would be some room for maneuver.
Software development is a business that aims to make money. If a client wants a custom project to be done for him and is willing to pay for it, your estimate will help determine the appropriate cost.
The requirements are passed to you, you say how long it will take to develop, the sales department converts the time into a monetary amount and informs the client, who then decides whether the desired is worth the cost.
Note… This does not apply to all software companies: not all develop to order. Unless you are a custom software developer, the scope estimates will be used primarily for planning purposes.
Key factors in the assessment
Now that you know what an assessment is all about, it’s time to figure out how to do it. The next time someone asks how long it will take to develop something, keep the following five key factors in mind.
1. Do not estimate how long it will take YOU
During the first two years of my career as a “evaluator” I was constantly trying to determine how long it would take to develop I have – but that’s not what they ask.
Remember that you are rating based on the productivity of the development team. Do not think that those who will do this know the subject area as well as you. Add a little headroom so they can explore the codebase and new area of expertise.
It is often helpful to assume that the least experienced on the team will do the job.
2. Don’t underestimate – overestimate
Remember, evaluation is primarily for planning. Therefore, there is no need to provide figures that, in your opinion, may be exceeded.
If the developers go out of your time limit, it will disrupt the work schedule.
It is normal to be in the range of 20%, but only if the estimate turned out to be overestimated – and not underestimated.
Whatever figure you come up with, add 20% to it: tasks are usually more difficult to implement than they seem.
3. Professional development
Will the team need to learn something new to complete the project? For example, if you usually develop applications for fat clients and a new project is creating a web page.
If there are components that require the acquisition of new skills (training), take this into account in the assessment. Give the team time to learn all the intricacies of new templates, languages, frameworks, etc. – this will still have to be done, so the time for learning should be included in the assessment.
4. Examples of similar projects
The easiest way to evaluate projects is based on templates already familiar to the team.
If the team has some basic material in the form of previously developed software, then the amount of work can be significantly reduced. It is easier for developers to act on the copy, paste, replace principle, and this is reflected in the speed of completion of tasks.
Be sure to consider if this company has done something like this before. If you have specialists who have been involved in this kind of projects, consult with them when evaluating and be sure to use their code as an aid in development.
5. Don’t forget about analysts
Often you will be asked for a full assessment, and this includes the time of developers, business analysts, and quality assurance specialists.
In this case, it will not be enough to assess only the developers – you need to take into account that business analysts will have to write documentation, make user stories and manage sprint reviews.
It will also take into account the time it takes for the QA department to test. Perhaps you have some kind of automation system that needs to be configured for this project too? All this takes time, which is also included in the assessment.
It takes time to learn how to evaluate the volume of work. This skill, like any other, takes practice.
Grades will become easier for you over time. Remember the points listed, learn to understand how long it takes to develop certain elements, and rely on your experience.
To summarize the most important things, remember this:
the task is always more difficult than it seems, and it is better to overestimate the amount of work than to underestimate.
No one will be angry if everything goes according to plan – the bosses will even be glad! And at the same time, you will have more time for other projects.
So feel free to set aside more time and remember that evaluation is just an evaluation.
About the translator
The article was translated by Alconost.
Alconost deals with localization of games, applications and sites in 70 languages. Native native translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any string resource formats.
We also do promotional and training videos – for sites that sell, image, advertising, training, teasers, explainers, trailers for Google Play and the App Store.