If I tell you, that we are mostly simply guessing, when we say, that we are estimating, you might be outraged, but how come, that our planning does not work out, even so nothing unforeseen has happened?
The misunderstanding starts with what we understand as »estimating«. Without any unnecessary talk, my understanding of guessing and estimating is as follows:
An estimate is a prediction based on verifiable facts, while guessing is based on feelings.
One of our main goals is to be very precise in our predictions. This does not only bring trust in our work with the customer, we also need that, if we work with other teams on one project. When we are not able to live up to our predictions, because our estimations were wrong, and that affects other teams, we will start having discussions, that might not be very funny.
If that happens once, nobody will say anything. It just can happen, and we can deal with it. If it happens regularly, we have to look for reasons, and most of the times the reason is, that our estimations are just rubbish.
One possible way out of this dilemma is to include buffers. In my experience, however, that only leads to your refinements becoming even sloppier. At some point even the generous buffers are no longer enough.
Our wish is to get a very good idea of what to expect in the refinements. If we even deal with the questions about implementation, we get even deeper insights. We have to talk about implememtation anyway. We can do this before the sprint to get a better idea of what to expect, or during the sprint to go into planning with bigger question marks. You decide, what might be the better idea.
A part of our refinement should ultimately be a »fact check«. We get a request, and our development colleagues have a few things in mind: you have to do it like this, it takes me about as long, something similar was about as time-consuming last time. All of these considerations are good and correct, but if we leave it at that, our guess is based on a feeling because none of these guesses (which are also very vague) have been verified in any way.
If we start verifying our wildest guesses, we go into our planning with more confidence and our predictions and commitments gain precision.
Everything wonderful, so we start to check every single thing, right?
No. We could doublecheck everything, to be absolutely sure with everything, but we would also create an atmosphere of general mistrust. Furthermore, fact-checking every single statement creates a lot of work, so the key to success is once more balance.
If a colleague tells me, that he has very deep knowledge in one corner of our project, I just believe him. But if someone says, that he thinks that this or that, than there is nothing wrong with asking him to check things out very briefly so that, in the worst case, the cow does not explode under our asses when things happen to be a little bit different than assumed.
The key-phrase is of course balance. We do not have to check every smallest thing. We do not have to doubt every single input of our colleagues, but when we start to differentiate between assumptions and knowledge, and be consequent with that, our estimations will gain precision.
The second trap, we like to step into, is comparison. Our requirements are not always completely new. Things do repeat itself. Very often we get the chance to compare something new to something that we did a little time ago. We wonder, how much work we put int it back then, take that number as an estimate for our new tasks.
In principle, not much speaks against it. One could now check where the differences lie in the requirements and the associated implementations. If we come to the conclusion that this does not have a major impact on the effort, we are encouraged to copy the price tag of the old requirement and stick it on the new one.
Too bad, that our memories tend to be deceptive.
Do yourself a favor – even if it hurts – to aks your colleagues, how expensive a past request has been. You will probably get different statements, because time is perceived subjectively, even if we use an objective measure such as hours and days. Then check together, how good your memory actually was, if your documentations allows it. I am sure, you will be surprised.
If nothing unusual has happened, we tend to shorten the periods of time in our memories: it wasn’t that time-consuming, I sat there for a day at most, but in fact it was one and a half. And that adds up.
We do not blae anyone for this. We only find, that feelings and impressions overlap and distort facts. Our wish is to free the facts from those distortions.
Once again: we do not overdo this. The more we doubt the input of our teammates, the more mistrust we introduce in our team, and that is something, we definitely do not want. Therefore, I advise you to be very open with this sort of things. Explain why you want your colleagues to check one thing or another. And we definitely do not anything behind the back of our teammates (I do not think, that I have to say that, but I say it anyway, because it is so important). We check those things together. As the one with the doubt, I am not the one to withdraw and check on everything on my own. That would have a very unpleasant aftertaste.
If we check something, and my colleague’s first statement has proven to be correct (which happens often enough), then I should be the first to say: sorry that we had to sacrifice the time now, but I am better now because I have gained security.
Over time we will adjust to a good level.
Core: If we use assumptions as the basis for our planning, there is a high risk of bad planning. Our goal should be to replace assumptions with certainty as much as possible. This creates more planning security and thus better collaboration across team boundaries.
If you need any assistance or want to know more, just speak to me.
