You're not going to change my mind; I've been lying, err, doing estimations for over 15 years, and I've lied for the majority of them. And if I were a betting man, I'd wager a month's salary that you, too, have been lying. Either to your manager when they request your best estimates for a specific task, or to yourself if you believe what you're saying is correct. There is only one thing that has helped me come to terms with my estimations and turn them into something somewhat trustworthy and somewhat accurate: assumptions.
And today I'd like to discuss assumptions.
What exactly are assumptions?
Every time we estimate something, we run the risk of discovering unknowns along the way. For example, while estimating the time it will take to develop the UI code for a new feature, you don't know if the back-end will be ready to be integrated and tested alongside your code. Can you complete the UI without the back-end? That is an unknown; you can't be certain that what you do will work with the final version of the back-end until you have access to and use the real back-end.
How can you provide an estimate if you don't know what will happen with the back-end code in the future? You could contact that team and inquire about their timeline. You can then adjust your own timeline based on that. But what if your unknown is the result of an external dependency? What if you're in the process of estimating the development of a completely new project to be deployed in Azure? You can try to estimate the time the development process will take and use that to provide an idea of the project's end date. However, you are unsure whether your client will have the credentials ready for you by the start date. How can you ensure that they do? What will happen if they don't? Suddenly, your estimated end-date no longer holds true. Were you telling the truth?
That's the issue, the real issue with estimates:
you have no control over what happens around your project and how real-life will affect it. And if you try to estimate based on those conditions, you'll almost certainly end up lying unintentionally.
Every unknown increases the possibility of error in your estimate. The larger the project and the further in the future you estimate, the greater the error in your final number. How can you give an estimate that isn't completely erroneous?
Assumptions are the correct answer.
Making Assumptions in Your Estimates
Every time you discover an unknown in your future, it represents a possible branching of your current timeline.
Have you ever heard of the experiment known as Schrödinger's Cat?
Essentially, the thought experiment states that you will never know the outcome unless you look inside the box and crush all potential futures (in this case, all two of them) into a single possibility.
Assumptions are analogous to the opening of a box. Every assumption condenses all possible futures around it into a single one and eliminates the unknown:
- "By the time the project initiates, all Azure certificates will be ready."
- "By the time we begin operating on the UI, the back-end will be glad."
- "The log file's dimensions will never overextend the 200Mb line."
- "The API will be obtainable 99.9% of the moment."
This way, your projections are based on a "real" future. You've eliminated the unknown from your path forward.
You've figured it out!
Your estimates will change from "I'll be done in two weeks" to "I'll be done in two weeks as long as the following assumptions hold true." Your final number is now entirely dependent on those estimates, and if one of them is not met, your estimates are no longer valid. That's also fantastic. You have no control over the future, nor do you have any control over external entities. As a result, the only reasonable course of action is to assume what they will do and plan accordingly. You can't be blamed if they don't behave as you expected, and you can't be expected to forecast every possible future scenario. However, you could provide estimates for the most common ones, sort of like having a plan A, B, and possibly even C. But that's all there is to it; the list of potential problems is infinite, and you can't plan for every possible combination of them.
Just make sure that for each estimate you deliver, you write down your assumptions and include them as part of the estimate. That way, you're sending out a contract that says, "This is my estimate, and it only applies as long as my assumptions are correct; otherwise, the estimate must be reviewed and adjusted accordingly."
That is how a software estimate is made.
All estimates rely on assumptions. They assist you in providing reliable numbers while also establishing appropriate expectations between you and your stakeholders. As long as they agree with your assumptions, you're all on the same page when it comes to each other's expectations. What are your thoughts? Have you ever made an assumption? Are you opposed to them? If you have any about the above topic. Don’t hesitate to contact us. Airo Global Software will be your digital partner.
E-mail id: [email protected]
Author - Johnson Augustine
Chief Technical Director and Programmer
Founder: Airo Global Software Inc
LinkedIn Profile: www.linkedin.com/in/johnsontaugustine/