Show Menu

Project estimating Cheat Sheet by

How and why to estimate

What we estimate and why it is important

Effort vs duration
Activities often take longer than planned even though the effort has not increased
Effort = amount of work if one person were doing it
Duration = actual amount of work with however many people available doing it
The effects of over- and under-­est­imating
Project can fail due to budget being exceeded
The allocation of not enough money can result in substa­ndard work as staff work extra hard to produce what they can
An excess­ively high estimate may lead to the work being lost to a competitor
Parkinsons Law (‘work expands to fill the time availa­ble’) means that an exces¬­sively generous estimate may lead to lower produc­tivity
Estimates and targets
Hard to be exact
An estimate of effort or time is really a most likely effort­/time with a range of possib­ilities on each side of it
Choose a target:
Aggressive – could get done quickly but high chance of failure
Generous – likely to expand the length of time needed, but have a safer chance of the target being met’
A reasonable target can become a self-f­ulf­illing prophecy


If you are using someone elses estimates, if you can then ask them:
What methods were used to produce the estimates?
How is the relative size of the job measured (in other words, what are the size/e­ffort drivers)?
How much effort was assumed would be required for each unit of the size driver (in other words, what produc­tivity rates are you assuming)?
Can a past project of about the same size be identified which had about the same effort?
If a job with a comparable size cannot be identi­fied, can past jobs which had similar produc­tivity rates be found?
Estimation best practices
Use the most reliable data available
Spend as much time as possible to produce the estimates
Use approp­riate methods
State the basis of the estimate
Establish best practices through lessons learned

Using expert judgement

Use completion of other tasks to get inform­ation for estimates
You need to know:
What activities are going to be carried out
How much work for each
The best person to tell us about the time it takes to complete a task is someone familiar with the tasks to be carried out and the enviro­nment in which they are done
People doing the work are involved with the estimating process
Involves the people with the best experience of similar work and work enviro­nment in the past
Task may be a new one of which there is no prior experience
Human error
Estimate is essent­ially a guess and its hard to know how accurate
May need to talk to several ‘experts’
The Delphi approach
A group of experts are asked to produce, indivi­dually and without consulting others, an estimate supported by some kind of rationale
Replies collected by a moderator
Circulated anonym­ously
Everyone reads everyone else and has opport­unity to revise opinion
Opinions should converge on a consensus

Estimating by analogy

The function point approach (and, indeed, the more generic approach of using size drivers and produc­tivity rates) is based on the assumption that we have the details of the size driver values and actual effort of past projects. Often, however, such records do not exist.
Analogy or compar­ative approach could be used.
Identify the key charac­ter­istics of the new project.
Search for a previous project which has similar charac­ter­istics.
Use the actual effort recorded for the previous project as the base estimate for the new one.
Identify the key differ­ences between the old and the new projects (it is unlikely that the old project is an exact match for the new one).
Adjust the base estimate to take account of the identified differ­ences
If there is no single past project then use parts of old projects

Agile estimation

Need a way to estimate that:
Allows budget creation
Plans for the future
Reminds us that estimates are guesses
Acknow­ledges inherent comple­xities and uncert­ainty with software dev
Keep things simple – estimate includes everything
Be fast
Relative sizing
Estimating absolutely is harder than relatively
Relative sizing means how big is this compared to that
How fast can the team go
Size stories relatively
Set expect­ations around dates
Agile estimates are unit less
Point based system
1 point = small, no sweat easy
3 points = medium, bigger but we can handle it
5 points = large, this will take some effort
Sit down with customer, ask a lot of questions, guess how big this is
Do this for each part of the project
Do it better as a team – get team involv­ement
Agile because there are problems with waterfall estimates:
- Clear on being guesses
- Usually overly optimistic
- Beginning has too many unknowns
- The only question we should be attempting to answer at the beginning is “is this project even possible with the time and resources we have got?”

Approaches to estimating

Bottom up (analy­tical or activi­ty-­based estima­ting)
Break the task into component sub-tasks
and then break the component sub-tasks into sub-su­b-tasks
And so on, until we get to elements that we think would not take one or two people more than a week to complete
To get an overall estimate of the effort needed add up all the effort for the component tasks
Recomm­ended if you have no historical records of relevant past projects to guide you
Disadv­antage: time-c­ons­uming as you have, in effect, to draw up a detailed plan of how the project is to be carried out first
Top Down
Look for some overall charac­ter­istics of the job to be done
From these, produce a global effort estimate
Nearly always based on our knowledge of past cases

Parametric approach

One way of base number calcul­ation in top down
Size drivers:
Number of variables to be completed
Other drivers often include:
Availa­bility of tools
Commun­ication overheads, including time waiting for approval
Stability of the work enviro­nment. (Risk of changes to resources and requir­ements)
Size of the project team. Larger jobs with lots of people involved are often less efficient
Function points
Not all IT projects involve writing software
Many use off the shelf
If do need progra­mming tradition to use lines of code to estimate the size, but problems with this:
The code is a very technical product – it would need a software expert to estimate the number of lines of code
You will not know the exact number of lines of code until quite near the end of the project; most other size drivers are known at the beginning, or at least at an early stage, of the project
Lots of languages and some need less code
Better to use function points which estimates the amount of work based on the outputs of the project / features of the program
We can use a function point count to find out the relative produc­tivity of develo­p-ment projects that have already been completed


No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Monopolies Cheat Sheet

          More Cheat Sheets by NatalieMoore