🤔 Why Do We Need to Estimate Software Projects?
📉 Why Is It so Difficult to Make a Perfect Estimation?
✅ How Do We Estimate Time for Software Development in Stormotion?
🎁 Bonus: Ready-Made Software Estimations by the Stormotion Team
When we at Stormotion start working with a new client, he usually asks us to make a software development time estimation. We also prepare it for our potential customers who drop us a letter with details about their project and willingness to cooperate.
However, time estimation in software development isn’t that fast & easy as it may seem. This process requires experience, knowledge and includes hidden pitfalls which we’ll teach you to avoid today. Let’s start!
Despite it may look simple, an estimation process is quite a challenging task (image by Lukáš Straňák)
If you already know all benefits of a good estimate, move right to the practical part!
Properly made software estimations are quite useful at the planning stage and further. They allow developing a realistic scale of efforts required on a specific project-phase. This usually includes:
Estimates provide many useful info (image by brian hurst)
As a rule of thumb, software development time is the number of hours which will be required to implement a requirement of the Product Owner. Such a requirement can be for example: a feature, a user story etc. The sum of hours needed to implement all the requirements makes up the estimate of the whole app.
Estimations are quite useful for all kinds of projects, including the ones that use agile-based frameworks.
Despite the classic Scrum approach doesn’t have an estimation stage in its structure, this kind of information turns out to be extremely helpful when you need to distribute features from the backlog between sprints for your remote team.
Scrum sprints usually aren’t changeable after the work starts. It means that estimates can help your Product Owner prioritize feature development and group them in such a way that allows delivering an increment on time.
Estimates help correctly prioritize feature development (image by Austin Golownia)
The same is true for the Kanban framework!
Since it’s based on the idea of continuous development, your team should constantly have enough tasks to keep working. The main challenge for a Product Owner is to prioritize them according to the business goals, deadlines, available resources etc.
But to prioritize it correctly, you’d better know how much time and efforts development of each feature can take. That’s when a good estimation comes in handy! With its help you’ll be able to create a development queue that matches your capabilities.
Moreover, since cycle time is a key metric for Kanban teams, an estimation will let you check whether the team does well or goes off the track.
How to Prioritize the Feature Development
Let’s review several real-life examples from Stormotion clients:
✅ How software development time estimation helped
One of our clients got a limited Angel Funding – €30,000. Is it enough to build an app MVP?
An estimation provided him with info on both total development costs as well as the price of each specific user flow. Thus, he found out that his budget meets all his needs and none of the features should be removed at the MVP-Stage.
An e-Commerce needed to convert a mobile app from iOS to Android. What is the best way to do so?
After estimating software development time, we found out that the development required 2.5 months with next support on a 10-hours-per-week basis.
Our German client needed to hire a remote developer to supplement his In-House team for one specific project.
Our estimation clarified the scope of work, helped to understand the needed amount of time to perform all the tasks and, therefore, correctly plan the budget and timeline for the project.
Estimates provide value to both sides of the development process in one or another way:
👩💼 For the client
👨💻 For the team
Provides info on the approximate time required to complete the project. This is especially important for projects with strict deadlines (certain promises to customers, a planned presentation during a particular industry event).
It helps to delineate the scope of the work and set adequate deadlines inside the team.
Provides info on the approximate cost range of development (and whether it fits the current budget).
Used to define the optimal number of developers needed to do all the work on time according to the contract.
Allows both parties to manage budget expectations - client knows the budget in the best and worst case.
Software development time estimation helps to calculate planning metrics (like cycle time in Kanban or velocity in Scrum).
As you can see, a good estimation provides some value to all shareholders. However, creating one isn’t an easy task. Let me explain why.
Despite many call estimations none other than predictions, they’re not the same as unjustified guesses. A correctly prepared estimate is always based on knowledge and experience of the team who is writing it.
However, when you try to estimate time for software development, it sometimes looks like this:
Estimations sometimes look like that story about the bicycle (Zamir)
This story can go on and on, and the estimation will change every time when the new condition is set. And this is what often happens when you’re estimating software development time.
So, the first reason is that any developer doesn’t have a 100% protection from unforeseen issues with performance, libraries, environment, architectural imperfections, APIs integration and so on.
However, unforeseen issues don’t relate only to the technical side. We’re all human beings that can get sick, have an emergency case or anything else.
Second, it may be difficult to estimate time for software development because of estimator’s individual characteristics. Every developer, depending on his experience, knowledge, general productivity and even physical or mental state at this exact moment will have a different working pace.
Image by Aleksandar Savic
However, it’s quite reasonable that clients shouldn’t pay 3 times more because someone works 3 times slower than an average developer. To prevent this, estimates are usually reviewed and corrected (to be more justified) by a more experienced tech-person (as a rule of thumb, a Senior).
Third, it’s difficult to estimate software projects precisely because sometimes changes come from the client’s side, too. For example, you decided to implement additional functionality or, on the contrary, to remove some pre-planned features.
However, all of the above doesn’t mean that it’s absolutely impossible to make a credible time estimation in software development. Look how this process is organized in our Stormotion HQ!
Since after an initial call we’re replying to all estimation requests which we receive - our team has designed a specific workflow for answering them.
Before estimating software development time we need some input - information that can help us understand the ground features of the project.
At the first stage we gather as much information as possible (image by maryanne)
We usually get it from 2 main sources:
Then our tech-crew processes all this data and uses it to draw the first version of the estimate - a rough one.
This kind of estimate is usually prepared within 24 hours and consists of 2 parts - Min and Max Estimates (or Best Case and Worst Case Scenarios).
Since it’s prepared using limited info about the project, it’s difficult to provide the client with a 100% accurate breakdown. Instead, we offer 2 figures that indicate both the highest and the lowest possible development time and costs.
Rough estimate provides many benefits to both developers and clients (image by Laura Reen)
The more information we manage to gather during the first step, the better our estimate is going to be. It will let us face a lower level of uncertainty and, thus, reduce the range between the highest-lowest figures.
Tip: If you earlier had an experience with a project similar to the one you’re working on now, you may compare them and use it as a ground for your estimation. When reviewing the old project, take into account actually spent (and not estimated) time.
Rough Estimates are essential for our clients since they help to understand the real scope, length and budget range of work.
Then, if everything is fine and our calculation matches the client’s budget - we’re either moving to the Discovery Phase (in case there are some tech-challenges which need deeper research) or move to signing the contract right away.
Sometimes, if the client has no info about the project except some use-cases (e.g. no wireframes), or there is a hard API or technology, which we need to research before giving a cost-indicator we propose our client a Discovery Phase, which lasts 1-2 weeks.
During this time we hold a few more video conversations with our client, develop our own wireframes, prepare an interactive Marvel/Invision prototype (like the ones in our articles about Pocket Promoter and Hotel App Development).
During the Discovery Phase we examine the project from A to Z (image by Nick Slater)
Also, we pay special attention to tech challenges that may occur during development - for example, how we’re going to implement machine learning side or integrate non-common APIs.
Pro’ estimation software development tip: if any task takes more than 8 hours we split it into sub-tasks. When making a Rough Estimate we try not to exceed the limit of 30 hours for 1 task.
Eventually, our client receives the final detailed version of the software estimate with the most realistic figures.
P. S. We’re going to dedicate a special article to the Discovery Phase so stay tuned.
Now we reach the part of the article with practical tips. This is what you came for, isn’t it?
Despite estimations always have a single aim, ways to reach them can be different.
The first approach is the most common and widely used since it’s pretty fast, easy and understandable. It usually involves 2 people: the one who will work on an app and the one who will do the estimation of software development (preferably a person not related to the project).
Why shouldn’t it be a single person? Despite it may seem quite logical that the estimation is done by someone who will then work on this project (since this person understands own capabilities better than anyone) this is not the best approach.
The classic approach is one of the most used across the globe (image by Anton Fritsler (kit8))
The problem is that when developers estimate software development time of their own projects they’re usually disposed to put more hours than it really takes. Actually, it doesn’t even matter why it happens - because they just want to work more slowly and get more money from you or because they want to have additional time to solve unexpected issues.
So the best solution is to involve another tech-guy, who can write the estimation for the person which will perform the work.
This specialist should be more experienced (a Junior/Middle can’t make an estimation for a Senior, but a Senior can make one for both of them) and interested in an objective result. His workflow consists of the following steps:
This approach is widely used by our team as well.
P.S. It’s also possible for an estimate to be written by someone who will then work with it, but it always should be checked by another, more experienced and objective person.
Moreover, as you could notice in our articles about app development, we usually try to break down the tasks into smaller sub-tasks to make our rough project estimates more accurate. Take it as a tip 😉
If you have a few developers working on the same project, the classic approach may work not that well. Instead, you can ask your Agile team to prepare software development time estimation jointly.
Such an approach would be called Planning Poker or Scrum Poker.
In this case, each developer has special cards with values on them (for example, 0, 1/2, 1, 3, 5, 8, 13, 21, 34, 55, 89). The numbers represent Story Points or any other items that indicate how difficult/long it is to create the feature. Later these cards will be used for voting.
An example of poker planning cards (image by Andrew Millar)
The whole estimation software development process goes as follows:
It’s important to notice, that all the decisions are made by discussing and through consensus - not by averaging all the values after the first round.
Scrum Poker has a few significant advantages which turned it into one of the most popular software development time estimation techniques:
Our regular readers and newsletter subscribers know, that each Stormotion’s article about app development is supplemented with an estimation.
As we mentioned it earlier, these estimations are true only for our developers and only for the apps described in the articles. If you want to see the full detailed estimation, click on the name of the app and you’ll be redirected to the appropriate page:
Approximate Time (in hours)
🛵 Food Delivery App (customer, courier and web apps)
509; 334; 139
*- without BackEnd
These were our insights on time estimation in software development. They will be useful for Agile teams no matter what framework - Scrum or Kanban - they use. Also, estimates are helpful to use as a bussines owner since they make the scope of work and possible budget more understandable.
If there are any questions left, feel free to drop us a line!
We hope that our experience and tips will help you to create a perfect estimate for your future projects. Also, don’t forget that you can get a free estimate from the Stormotion team within 24 hours. All you have to do is just contact us by hitting the button below.
Was it helpful?
How We Handle Quality Assurance (QA) in Stormotion
How Much Does It Cost to Develop IoT Software?
The Stormotion Team: What Makes Us Special?
Our clients say
They were a delight to work with. And they delivered the product we wanted. Stormotion fostered an enjoyable work atmosphere and focused on delivering a bug-free solution.
David Lesser, CEO