I suck at software estimates. And I bet you do too. So many software projects get delivered late. I am getting better at them, but it is going to take time. Let us consider a few reasons why they are so challenging.
Not Enough Time
This is a problem that is often overlooked. Worse still, managers often do not understand that this a problem in the first place. There seems to be this idea in some of their heads that developers know how they are going to solve the problem as soon as it is given to them.
The reality is that developers are often given tasks so poorly defined that they barely even understand what the problem is. They have to dig through unfamiliar code. What snares lie in wait for them there only God knows. Even after digging though that code and hounding people for better requirements, they only have a faint idea of how they are going to approach the problem. And the approach will likely change tomorrow.
So if a meeting gets called to introduce a brand new project and get a rough estimate of how long it would take, that estimate is going to be wrong. It is just guess work at that point. Coming up with a reasonably accurate estimate takes work, and steps cannot be skipped.
Not Breaking Things Down
This is such a simple concept, yet I am guilty of neglecting it all the time. How many of these lines do you catch yourself saying?
Ummm it would maybe take a sprint or two?
I should have that done in a few days.
I don’t see it taking more than a week.
You can hear the underlying message. The person uttering phrases like these has not broken down the development task at all. Does this developer know which methods he is going to write? How the different components will interact with each other? How the code behaves today? What automated tests need to be written? The only effective way I’ve found to produce reasonable software estimates is to estimate small things and add them together. The bigger the task is the worse we are at estimating it because by its very nature we are omitting important details. It is much easier to accurately estimate “Write a method that checks if a string is a guid”, than it is to accurately estimate “Write a point of sale system”. The further you can break down your tasks the better off you will be.
Forgetting About Other Stuff
We are all more than our jobs. We have a life outside of work, and sometimes we forget about that when we are making our estimates. Vacations and doctor’s appointments should be considered. If you are a leader on your team you also need to consider how your absence will affect the more junior members of your team. Will you need to leave more concrete direction for them? How much time will that take? You also need to think about what a typical work week looks like for you. The truth is, on any given day we often find ourselves working on just about everything except what we thought we were going to. Those disruptions and urgent requests can be really unpredictable, but they must be considered in order to produce realistic estimates.
How can we get better?
The first step in getting better at software estimates is to communicate well with your manager or product owner. Ask for some time to come up with an estimate. You probably won’t get as much time as you want, but it is way better to put a little thought into your estimate than to put in no thought at all. This is crucial because you can’t break down the task instantaneously. This step must happen for any other advice here to be helpful. With this accomplished you can begin to plan the work and start uncovering the time consuming tasks that are currently shrouded by the veil of your ignorance. If you can identify these up front you are really helping yourself out. That is really the key to it all: gathering more information about the future. The more information you have the more accurate your estimation will likely be.
It is really a shame my manager won’t let me make my estimates after the project is complete. I would be perfectly accurate!