Agile or not you need a better estimation technique: PERT
PERT (Program Evaluation and Review Technique) was initially developed by US Navy to take care of scheduling uncertainties but we are going to use it to have more reliable time estimations. This is crucial when talking to a customer as well for the internal organisation of resources and time.
This technique can also be used by companies or freelances as help for their pricing strategy.
Open the links at the end of the article and use one of the tables, your project’s estimations will look wonderful.
Let’s talk about how to PERT. It’s really easy to understand and even more to use it.
We need this? Really?!
Yes! Because misleading or changing estimations are the first cause for a project to diverge from customer expectations or budget constrains. [1] [2]
From Agile standpoint we should make estimations with the collaboration of the client, from the Waterfall standpoint we should make the estimations only when the specifics are correctly gathered and crystal clear. In practice, sometimes we’ll be asked to estimate a project without any relevant information or guessing a number of days eyeballing the design of a screen that was drawn without, again, all the specifics.
How come that the most important document about the project to-be is so often and violently disregarded? How can we prepare to give a professional performance in spite of everything, in such conditions?
We can roll a dice, we can look at the stars, we can hope for a sign from above, or we can try to add some coldness to the process and add some math to it, just about the amount not to be too optimistic or too pessimistic.
It’s a table
There is a way to improve our estimations following a fast, clear process that can take place on Notion or on a Google Spreadsheets. It is a fairly complex table very straightforward to compile: we’ll only need a new row for every user story or task that we are planning on the project and to give multiple estimations (can be scrum points, hours, days, seconds!). Those estimations will force us to rapidly think about what can go wrong and how much it can slow us down. The final result will take into account those potential problems and will help us tu have a more real picture of the project timing.
What follows is the list of columns, from the said table, orderly explained in a way that (I hope) makes sense.
Activities
A list of epics, user stories, tasks or features fairly unpacked.
Toggle
A checkbox that let us turn on/off the activity itself from the calculations.
Estimates (optimistic, likely, pessimistic)
A value that estimates the time we’ll use to complete the task. It can be hours, days or scrum points and we give our optimistic, pessimistic and most likely time estimation.
Weight average (expected time)
We calculate the average over the previous 3 estimations but we add more weight to the most likely value because, well… it’s the most likely
Note: A less used variant of this is the “Triangular Distribution” that only calculates the standard average.
Expected time is optimistic + 4 * most likely + pessimistic, all divided by 6
t = (o + 4m + p)/6Standard deviation
We calculate the standard deviation over the 3 estimates (optimistic, pessimist and most likely) to measure how those numbers are far apart.
A low Standard Deviation indicates that the observations (series of numbers) are very close to the Mean. A high standard deviation indicates that the observations (series of numbers) are spread out over a large range.
Example:
A: (3, 4, 5)
B: (1, 4, 7)
A and B tuple have the same mean but B have numbers more distant to one another. This shows that you can literally deviate more from the mean.
We calculate it pessimistic — optimistic, all divided by 6
σ = (p — o)/6Estimation
Calculating the standard deviation means that we can distribute our estimations over a Gaussian curve. As you can imagine a higher standard deviation will shows a flatter curve (anything can happen); a low standard deviation means the curve will be more pronounced (the most likely estimation has good chances to be right):
Now using the Probability Distribution theory, we can determine the probability associated with a range. This probability is also called the Confidence Level.
The final estimation will be the expected time +/- the deviation for its n probability
E => t ± (n * σ)Following list provides probability for different values of ‘n’.
- If n=1 then probability is 68.27%
- If n=2 then probability is 95.45%
- If n=3 then probability is 99.73%
- If n=4 then probability is 99.994%
- If n=3 then probability is 99.99994%
- If n=6 then probability is 99.999999%
Days (or another unit of measure)
We only use this column so that we can link it with the toggle checkbox and switch on or off this task and have it calculated or not.
Real days (or another unit of measure)
We’re at the end of our journey, here take into account the entropy factor that troubles every project that has more than a few hundred lines of code.
💡 Entropy is a measure of chaos that either stays the same or increases over time. Stated another way, it is a measure of the inherent instability built into a software system with respect to altering it.
In simple words: the more your software grows, the more it takes to modify it and to build new features.
We use on our final estimation an entropy multiplier. The bigger the project, the higher this multiplier will be.
rd = E * enThe resulting number will probably be the right amount of time needed for that user story or task!
Resources
The table is ready to be copied from notion here:
Link Google Sheets → PERT Estimation Template
Link Notion → Program evaluation and review technique — Table
On this one I used days as unit of measure, so with a simple formula I know the price of the single activity. With the conditional formatting is also possible to visually find the longest activities; when something is too big it’s probably best to split the activity in two parts or more.
You can configure the desired confidence level, entropy and daily price on the second sheet called configuration
References
[1] The Clients’ Impact on Effort Estimation Accuracy in Software Development Projects [link]
[2] The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates: A Randomised Controlled Field Experiment [link]
About me
I’m Alessandro Annini 👋, CTO of Nautes, the Italian one-stop-shop for your digital design and software needs.
When you need to build something from ground up or make a restyle we help you project your idea, we imagine and realize the UI with you, then we code the product using the latest technologies, the best practices and the safest cloud partners.
