ESTIMATION

The process of predicting the most realistic amount of effort

expressed in terms of person-hours or money
required to develop or maintain software based on incomplete,
uncertain and noisy input.

Effort estimates may be used as input to project plans, iteration

plans, budgets, investment analyses, pricing processes and bidding
rounds.
HOW TO ESTIMATE COST
AND EFFORT
1. Map Your Software Development Life Cycle
2. Check Your Project Requirements
3. Make a Work Breakdown Structure
4. Use a Software Estimation Technique
ROLE IN COMMUNICATION
Resource Allocation
Improving Team Morale
Managing Stakeholder Expectations
Product Quality and Technical Debt
 ESTIMATION
TECHNIQUES

10/12/2014 Chapter 23 Project Planning 4

ESTIMATION TECHNIQUES
Organizations need to make software effort and cost
estimates.
 Experience-based techniques The estimate of future
effort requirements is based on the manager’s experience
of past projects and the application domain. Essentially,
the manager makes an informed judgment of what the
effort requirements are likely to be.
 Algorithmic cost modeling In this approach, a formulaic
approach is used to compute the project effort based on
estimates of product attributes, such as size, and process
characteristics, such as experience of staff involved.
10/12/2014 Chapter 23 Project Planning 5
ESTIMATE UNCERTAINTY

10/12/2014 Chapter 23 Project Planning 6

EXPERIENCE-BASED
APPROACHES
Experience-based techniques rely on judgments based on experience of
past projects and the effort expended in these projects on software
development activities.

Typically, you identify the deliverables to be produced in a project and

the different software components or systems that are to be developed.

You document these in a spreadsheet, estimate them individually and

compute the total effort required.

It usually helps to get a group of people involved in the effort estimation

and to ask each member of the group to explain their estimate.
10/12/2014 Chapter 23 Project Planning 7
PROBLEM WITH
EXPERIENCE-BASED
APPROACHES
The difficulty with experience-based techniques is that a
new software project may not have much in common
with previous projects.
Software development changes very quickly and a
project will often use unfamiliar techniques such as web
services, application system configuration or HTML5.
If you have not worked with these techniques, your
previous experience may not help you to estimate the
effort required, making it more difficult to produce
accurate costs and schedule estimates.
10/12/2014 Chapter 23 Project Planning 8
ALGORITHMIC COST
MODELLING
Cost is estimated as a mathematical function of
product, project and process attributes whose
values are estimated by project managers:
 Effort = A ´ SizeB ´ M
 A is an organisation-dependent constant, B reflects the disproportionate
effort for large projects and M is a multiplier reflecting product, process
and people attributes.

The most commonly used product attribute for cost

estimation is code size.
Most models are similar but they use different values for A, B
and M.
10/12/2014 Chapter 23 Project Planning 9
ESTIMATION ACCURACY
The size of a software system can only be known accurately when it
is finished.
Several factors influence the final size
 Use of reused systems and components;
 Programming language;
 Distribution of system.

As the development process progresses then the size estimate

becomes more accurate.
The estimates of the factors contributing to B and M are subjective
and vary according to the judgment of the estimator.

10/12/2014 Chapter 23 Project Planning 10

EFFECTIVENESS OF
ALGORITHMIC MODELS
Algorithmic cost models are a systematic way to
estimate the effort required to develop a system.
However, these models are complex and difficult to use.
There are many attributes and considerable scope for
uncertainty in estimating their values.
This complexity means that the practical application of
algorithmic cost modeling has been limited to a relatively
small number of large companies, mostly working in
defense and aerospace systems engineering.

10/12/2014 Chapter 23 Project Planning 11

POPULAR TECHNIQUES
 PERT Estimate = (O + 4 x M) + P) / 6.
(M)ost likely
PERT ESTIMATION (O)ptimistic
(P)essimistic

The Program Evaluation and Review Technique (PERT) is a

statistical estimation technique used to estimate the time
required to complete a project by considering the expected
duration of each task and the dependencies between them.
PERT estimation is particularly useful for large and complex
projects.
It helps teams to account for the dependencies and has the
potential to provide a more accurate estimation of the overall
project duration.
But it can be time-consuming and requires a lot of
information about the project.
ANALOGOUS ESTIMATION
This method estimates the effort required to complete a project by
comparing it to similar past projects.
Start by identifying similar past projects and estimate the effort required
to complete the current project based on the effort required for the past
projects. This process is particularly useful when dealing with similar
projects or tasks.
You need to watch out for false positives – some similar-looking tickets
may not be so simple under the hood. Diving deeper into requirements
can help.

Good for: Any situation where historical data is available and easy to
access and analyse, unless you have AI help. You'll need strong codebase
knowledge (or AI) in your team to capitalize on this method.
AGILE ESTIMATION
Collaborative: Involving everyone on the Agile development team
because collaborative efforts lead to better estimates.
Faster than any traditional techniques. It recognizes that
estimations are a non-value-added activity and tries to minimize
them.
Estimation is not in terms of dollars or days; instead, “points” or
qualitative labels are employed for estimating or comparing tasks.
Top down
Retrospectives help refine the estimates for future
STORY POINTS
Unit of measure to define effort
Consider:
1. Complexity
2. Risk – random changes, unclear requirements, dependencies
3. Familiarity with the area
4. Estimation matrix (e.g., Fibbonnacci)
PROCESS FLOW
Identify user stories.
Discuss the user story requirements.
Formulate an estimation matrix: Numeric scale that helps evaluate
the selected task. E.g., Fibonacci sequence (…5, 8, 13…) or the
linear scale (… 3, 4, 5…).
Select a suitable Agile estimation technique
Carry out sprint planning
Ensure that the estimate consistency
SPRINT VELOCITY
The number of story points that a specific team can complete in a
sprint.
Calculated using historical data.
THREE-POINT METHOD
The Three-Point Method is used to estimate the time required
to complete a project by considering the best-case, worst-
case, and most-likely scenarios.
Using three values: optimistic, pessimistic, and realistic. The
average of the three values is then used to calculate the
overall estimation.
Useful when dealing with uncertain tasks or projects.
One problem with the Three-Point Method is that it
sometimes doesn't yield accurate estimates for uncertain
tasks or projects.
Good for: Large teams (though works at any size), complex
PLANNING POKER
Consensus-based estimation technique.

Team members estimate the effort required for each task

using a deck of cards with numerical values. The team then
discusses their estimates and tries to come to a consensus
for a story point estimate.

Could be time consuming

Good for: small to medium-sized teams, small- to medium-

T-SHIRT SIZING
T-Shirt Sizing is an estimation technique used to estimate the effort
required to complete a project by assigning t-shirt sizes (e.g., small,
medium, large, extra-large) to tasks.

Its simplicity attracts many agile teams as a method to assign story

points, but it's a magnet for inaccurate estimations. It's just too
reliant on subjective opinions rather than objective data, and too
reliant on a system that is open to interpretation – in my
experience projects driven by T-shirt sizing often go sideways
unexpectedly.
BUCKET SYSTEM
This one's really similar to our T-shirts. It works by dividing the
project into buckets or categories based on the level of effort
required. Too much lack of clarity, too much opinion.
LARGE SMALL UNCERTAIN
(LSU)
LSU categorises tasks based on their size and uncertainty. Identify the tasks
required to complete the project and categorize them as large, small, or uncertain.

The effort required for each category is then estimated, and the total effort for the
project is calculated.

It may be difficult to categorize tasks accurately, especially if the team members

have difference of opinion. It's important to ensure that the team has a shared
understanding of the task categorization before starting the estimation process.

Good for: Teams with strong codebase knowledge. Projects with uncertainty and
risk.
COST
Total points for backlog = 1000
Velocity after 2 sprints = 100
Total no of sprints needed = 1000/100 = 10

Resource cost per sprint = $900

Resource cost for whole project = $900 x 10 = $9,000
THE FUTURE OF
ESTIMATION
Human estimation is flawed. Our experiences and cognitive
limitations bias us.

AI based methods can leverage vast amounts of data and

sophisticated algorithms to generate highly accurate
predictions that are free from human bias.

As AI-powered prediction models continue to evolve and

improve, they will become an essential project planning tool
for any organization that wants to stay ahead of the
competition.
REFERENCES
https://www.projectmanager.com/blog/software-development-estim
ation
https://softwaredominos.com/home/software-design-development-a
rticles/software-effort-estimation-how-to-get-it-right-the-first-time/
https://www.netsolutions.com/insights/how-to-estimate-projects-in-
agile/
https://www.stepsize.com/blog/the-best-software-estimation-techni
ques