Why do we estimate?
We, the delivery team, estimate so we can predict the time is going to take us to finish a task. It could be a new feature, a bug fix or whatever. This way business people can have a rough idea of how long is going to take to have a code change in place.
But this is just an estimation. Not a commitment. We can’t say it’s going to take us 3 days and then rate success or failure depending if we met that estimate or not.
We are humans and we are not good making predictions. We are optimistic. Even if we could predict exactly how long a task will take many things could happen in between that we weren’t expecting.
Making predictions for long projects it’s even worse. If we are bad estimating for small tasks imagine adding up all those deviations.. Estimating a whole project it’s wrong. And that’s why we have agile or things like #norprojects. Even #noestimates.
So what do we do?
First, we are aware. Estimates are going to be wrong. So we will tell the business that our estimates are just predictions and tell them we are giving just a guess.
They are going to be wrong specially in the long term. So we will give estimates to the business within a sprint, one week or two weeks should be the longest. If they ask for a feature that it’s not within the scope of the current sprint we will say “Sorry, I don’t know”. If somebody comes and ask “when do you think the project will be finished?” we will say “Sorry, we don’t know. I could give you a day to make you happy but that would be just lying and I don’t want to.”
So we will be honest. We will be professionals and don’t tell lies to our managers or business people just to make them happy for the time being. Managers want to know when things are going to be finished so they can put in place all their figures and budgets and all of that, but using estimates for that it’s just lying. Also if we are working in a feature and we find an impediment which is going to slow us down, we will say it as soon as possible.
We will build trust.