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.
Have your own project in mind?
We can provide you with a free consultation and suggest further actions.
Inputs required for EstimationThere 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 workThis 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:
Development RisksRisk 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.
Tech stackEach 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.
Need a quote?
GBKSOFT team can help you with your project estimation and development! Get a solution that fits your budget and meets your key business goals.
Software Development Effort EstimationTalking 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?
The system we use to grade developersThe 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.
How we estimate the timeOnce 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.
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.
Some popular approaches to estimationWhile 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 approachThe 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.
- 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 approachAgile 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 approachWhile 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 estimationEvery 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 PointsStory 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 PokerPlanning 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 EstimationPlanning 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 sizesIt’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:
Bottom LineAn 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.
Looking for a reliable team to estimate and build your solution?
We have 10+ years of experience and very satisfied clients. Contact us right away to discuss your idea and get a real quote.