Software is notoriously expensive to develop.
It’s a complicated endeavor in which a team of various professionals can be
involved for months or even years.
Software development is also not a very exact process.
Yes, when building a minor feature to perform a simple task, you can be precise with
how much funding such a project will require. But if the product must solve a business problem,
this creates a lot of uncertainty. And uncertainty isn’t something that you
can easily put into calculations. So, how do we estimate software development
So, how do we estimate software development costs with this uncertainty in mind?
The lack of funding is one of the main reasons businesses fail. Not a reason per se, it’s more
of a symptom of poor financial management. How does it happen? In our tech-driven world,
software is created all the time, so why is it so difficult to prepare for future expenses?
The first mistake is something humanity is yet to solve – our irrational optimism.
This is called the planning fallacy, the concept that was first introduced in 1979. According to
studies, both in personal and professional lives, people overestimate that they will finish tasks
earlier than they usually do and rarely consider their past experiences with similar tasks.
Some teams also feel pressured by the stakeholders to provide smaller numbers. When you know that the
provided budget is way too low, but you want to stay in charge, you might agree
to unrealistic commitments, hoping that you’ll fix the problem somewhere along the way.
Besides, stakeholders often expect an exact quote too early in the process – before
anyone knows what they’re going to build and how they’re going to build it. Sometimes,
the discovery phase takes weeks or months to realize a fraction of the features that must
be built. Not many clients are ready to wait for that, but still expect realistic estimations.
It’s practically impossible to make clear estimates at the project start. Look at this
graph. It’s called the Cone of Uncertainty. In 1958, it was proposed as a standard for
estimation classification for construction in the chemical industry and since then has
been validated in project management. It illustrates that at the planning stage,
when the uncertainty about the product is the highest, all estimates are massively
different from the result. It means that if the project is estimated to take a year to develop,
it may end up realistically taking from 3 months to 4 years.
But the more developers learn about the project and start settling on some specifications and
design, the smaller the uncertainty is. As you can see, even at the final stages, some uncertainty
remains and up until the deployment, the exact duration of the project might be unclear.
Regardless, stakeholders need estimates on the project timeline and budget,
so how to deliver them at such high levels of uncertainty? You ballpark.
Planning typically starts with documenting the project scope.
You ask large, big-picture questions and break them down into manageable pieces that you can
assign to specific teams. The scope is described in the Work Breakdown Structure – one of the
first documents that projects start with. It can look like a list, a diagram, or a Gantt chart,
but it’s typically presenting the hierarchy of tasks and deliverables.
The Work Breakdown Structure allows us to sketch out the first version of the product backlog,
which will be the foundation for the team’s work throughout the whole development
process. So how does it work?
If you take your family on vacation every year,
you can approximate how much it will cost you this year as well.
In project management, this approach is called analogous estimating.
You take a look at a similar project conducted in the past and draw its data on duration,
the number of people engaged, and costs. Analogous estimating is always rough, but it’s
useful when you’re at the initial development stages and have very little information about the
new project. It’s very easy and quick to do, you only need an experienced PM or a team lead who’s
done some similar work and can approximately say how long each feature takes to implement.
The project’s size can be measured in different units, both absolute and relative.
Take ideal days. This is something familiar to any person who has to plan anything really. If
you were to work without interruption, how many days would it take you to finish it? For example,
a designer, knowing their past experience of doing similar tasks,
might estimate that it will take five days to design the homepage. But to be on the safer side,
they might double that to account for all possible interruptions.
Or, to simplify the matters, you can use t-shirt sizes. Write a list of large features or sections
of the app to be developed (they are often called epics) and roughly estimate if it’s a small,
medium, large, or extra-large task. You can then go look at the data from past projects,
see how many days it took you to finish tasks of similar complexity,
and use those numbers for a new estimate. Analogous estimation may work at earlier stages
and if you have very little time, but if you require something more precise,
you will need other methods.
Take, for example, parametric estimating.
In parametric estimating, you combine historical data with statistical modeling. Basically,
it’s a step forward from analogous estimating as it considers the difference
between the past and new project. For example, it took you 7 months to do
a similar project before and it cost $500,000. So one month of work costs $72,000. Now, the current
project will take 9 months to finish, and since one month of similar work equals $72,000, then
the whole new project will cost $648,000. And you can calculate the cost of any unit
of work, not just a month. For example, you can estimate how the budget changes
if you add more people to the team. This approach is more reliable, though it may
be time-consuming in more complex projects when you’re estimating the cost of separate features
and considering different variables.
Another estimation technique is three-point estimating.
As the name suggests, you develop three separate estimates.
One is an optimistic estimate, if everything goes as expected,
and all funds are spent efficiently. The second estimate is pessimistic,
the worst-case scenario, when the project goes over budget with massive overspending.
And finally, the most likely estimate, which reflects how it normally happens,
with some non-catastrophic expense losses. Then the final cost can be estimated
using the following formula.
This formula is called a Program Evaluation and
Review Technique (PERT) estimate and it’s one of the most popular and widely used estimation
techniques in project management. It’s considered to provide one of the most accurate results among
all methods, besides this last one. Finally, let’s
cover bottom-up estimating.
As you might have guessed, the bottom-up method makes estimates of work at the lowest
level of detail and crawls up before calculating a sum of all tasks.
This estimation is done by experts that will be directly involved in delivering the tasks they’re
estimating, so you can expect high accuracy. Here, every team can report how long it takes
them to perform a similar activity and then a project manager calculates how much they’ll
have to be paid. The crew can also highlight other resources and variables to be taken into
account. Although inaccuracies will still happen, they will level out in the final result.
Of course, such an approach requires more time and can increase the planning time and project costs
as well. If your project is time-constricted and stakeholders aren’t that concerned about
budget accuracy, it might not make sense to spend weeks doing precise calculations.
But bottom-up estimating may be done in high-stakes endeavors to
give confidence to stakeholders and reduce errors and overspending.
You must remember though that this initial ballpark estimation is just that…an estimation.
It’s not a precise plan and its only purpose is to help stakeholders understand how much work such
a project entails. The actual cost and effort can be calculated only during development. So
how is this done? Let’s talk about story points.
In agile development,
sections of the software to be developed are broken down into different levels.
The highest level is themes – long-term objectives shaping the product’s overall strategy. Themes are
expanded into different epics – larger features. And epics include several user stories.
Stories are told from a user’s point of view and highlight their desires and
intent. We highly recommend you watch our video on acceptance criteria for a detailed explanation
of this concept. The length and scope of software implementation are often measured in user stories.
For example, a login feature consists of five user stories,
the password recovery feature is two stories, and so on. And they are also used to estimate
the project’s effort, using story points. Story points have been in use in agile teams for
over 15 years and they’re a bit more complicated than rough day estimates. This method involves
assigning tasks a certain value relative to their complexity. For instance, 1 is a simple task while
8 is much more complex. Of course, complexity is subjective, which is why story points assignment
is often a team effort. Here’s how it works. This is a practice called planning poker. Each
team member has a set of cards with numbers or any units that make sense to you such as
the aforementioned t-shirt sizes. Then a product owner reads a user story
from the backlog and the team discusses it. After that, each person selects a card that
they consider an estimate of its complexity. When everyone’s ready, the cards are revealed.
If all cards have the same number, that’s great, you’ve got your estimate. You can
write down that this exact user story’s difficulty is five. But if everyone has
a different opinion, the team continues the discussion and votes once again.
If the range of estimates is too big, this indicates a different level of understanding
or uncertainty within the team. Say someone is confident a user story deserves just 2 story
points. Perhaps they know of a library that can automate the task. Or someone
else that assigned it 9 points sees hidden risks. Planning poker allows team members
to come up with interesting insights and be more realistic about task complexity.
Planning poker is most effective in smaller, targeted teams that are already familiar with
the project and each other. And it allows you to estimate how productive the team will be,
or its velocity.
In modern development, work is usually done in sprints.
Sprints, which initially came from the Scrum development approach, are short periods of
time (typically, two weeks to a month) when a team does a set amount of work. The number
of story points the team can complete within a sprint is their estimated velocity. Basically,
it describes the team’s productivity. To calculate anticipated velocity, you simply
add up the story points of all user stories that you plan to complete within a sprint.
Say, all your story points added up to 200. If your velocity is 20, meaning that you expect
to complete 20 points each sprint, then the whole development takes 10 sprints or 20 weeks. You add
to that a sprint at the start of the project and a sprint for release preparation, and you get your
estimation of 22 weeks for the whole project. Velocity is typically measured after the fact to
help plan ahead, so the estimated velocity of the first couple of sprints may not be precise
and it will even out as the team learns to predict their velocity better.
At the same time, if the project has a deadline and should be completed in, say, 15 weeks,
the team can calculate how many user stories can be finished by that time and perhaps add
people to the team to increase velocity or delay the deadline thus increasing the budget.
Regardless of how detailed your estimates are, a project manager will keep track of
the team’s performance and update estimates at different development stages.
This is a project management triangle. It illustrates three constraints of the
project’s quality: the project’s scope – its features; the project’s cost – the resources;
and time – its schedule and deadlines. To make sure quality doesn’t suffer,
a project manager must trade between them. If stakeholders want more features, then the
product needs more time to develop and a larger budget. Given that we don’t compromise quality,
of course. If the product is late for an important presentation, then maybe we should prioritize some
features and cut the scope or hire more devs and increase the budget.
The project rarely runs according to the original plan and schedule. Sometimes,
stakeholders want to take longer to discuss the product design – the extra week that wasn’t
included in the first estimate. A project manager will come to stakeholders pinpointing any changes
to the plan and propose solutions. That’s the magic of the agile approach in
development. If it’s not a fixed-cost project with detailed specifications,
angles of the triangles can be adjusted for the best possible outcome.
We highly recommend you watch other videos from our project documentation playlist. If
you enjoyed this one, let us know and share your experience of making project estimates.