Let me start by stating that estimations in our industry are one of the biggest lies we tell as developers. The worst part is that we tell those lies to ourselves as well.
Saying “Sure I can finish this in 2 days, I’ve done it several times already” is all that takes for Murphy to jump in and cause you to spend 3 times longer while working extra hours.
That’s a fact.
And while I do hate estimates, I’ve learned to live with them because everyone needs them and as long as both parties understand that an estimate is not a binding contract that needs to be fulfilled to the exact date, I’m OK with that.
However, over the years I’ve learned a trick or two regarding estimates and I wanted to share one with you today: assumptions.
What are assumptions?
Maybe you’ve heard about them before, or perhaps you’re already taking advantage of them. But in case you’re not, let me quickly explain it.
Every time we estimate something, there is a chance that we’ll find unknowns along the way. For instance, while you’re estimating the time it’ll take you 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 together with your code. That’s an unknown.
How can you provide an estimate if you don’t know what’s going to happen in the future with the back-end code? Perhaps you can reach out to that team and ask about their timeline. That would be a reasonable action.
However, what happens if your unknown affects an external dependency? What if you’re estimating the development of a whole new project to be deployed in Azure, but you don’t know if your client will have the credentials ready for you by the start of the project. How can you make sure they do?
You can’t. That’s the problem, that’s the real problem with estimates: you can’t control what happens around your project and how real-life will affect it.
The bigger the project and the longer in the future you estimate, the potential error in your final number grows. So how can you control it? How can you provide an estimate that is not complete BS?
Assumptions.
Making use of assumptions for your estimates
Every time you find an unknown in your future, assume one possible scenario and write it down.
“All Azure credentials will be ready by the time the project starts”
“The back-end will be ready by the time we start working on the UI”
That way you’re basing your estimates on a potential future. Granted, the keyword there is “potential”, but at least it’s something tangible. You’ve removed the unknown from your path ahead. You’ve solved the problem!
Now your final number is completely dependant on those estimates and the minute one of them is not met, your estimates no longer apply.
That’s also great. You can’t control the future nor can you control external entities. So the only reasonable course of action is for you to assume what they’ll do and plan accordingly.
If they don’t behave as you expected, you can’t be blamed, nor can you be expected to estimate for every possible future scenario.
Just make sure that for every estimate you deliver, you write your assumptions down somewhere and deliver them as part of the estimate. That way you’re sending out a contract saying:
“This is my estimate and it only applies for as long as my assumptions are true, otherwise the estimate needs to be reviewed and adjusted accordingly”.
That’s how you do a software estimate.
What do you think? Have you used assumptions before? Are you against them? Leave a comment and let’s discuss it!