by @Alessandro Annini
Open the link in the Resources section and use one of the tables, your project's estimations will look wonderful.
The rest is about how and why we calculate the values in the columns.
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.
We are going to use PERT (Program Evaluation and Review Technique) that was initially developed by US Navy to take care of scheduling uncertainties.
There is a way to improve our estimations following a fast, clear process that can take place right 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 epic or user story or task (whatever you got) 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.
A list of epics, user stories, tasks or features fairly unpacked.
A checkbox that let us turn on/off the activity itself from the calculations.
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.