If you’re reading this, you’re probably a developer. Being a developer myself and having worked with developers I know that one of the most dreaded questions for a developer is about time:
How long time will it take to implement this?
Most developer hates that question, simply because it is so hard to answer. Programming is about solving unknown problems. Often more than 50% of the job is already done when the problem is analysed enough to be known. We can’t do 50% of the job just to get a time estimate, we have to estimate based on experience of similar problems and experience of time estimating similar problems.
I’m often doing time estimations and I think I’m decent at it. I used to be mediocre. In this post I’ll try to share some experience of time estimation and my thoughts on how to improve time estimation skills.
Gather Estimation Experience
One of the keys to improving any skill is gathering experience. Having worked with Scrum for some years, I have now come to the habit of setting a time goal when I’m starting on a new task. Sitting in the office with my morning cup of coffee looking at a new task I try to think about it before I start.
This doesn’t look to hard, but there are quite a few fields in the database and forms. I should have the database and data access done by lunch and the entire add/update form done today before I leave.
I’m not telling my estimate to anyone else and I make no commitment to anyone but my ego about being finished today. But I’m doing an estimate before I start and when heading off for lunch I do remember what my goal was before lunch and for the entire day. Continuously estimating and monitoring the estimates is the only way to gather estimation experience.
Disaster Analysis
Another way to gather estimation experience is to perform disaster analysis. When a project goes over the initial budget there is something to learn from that too. In my experience there are five main reasons that a project goes over the budget:
- Some tasks needed were simply forgotten when doing estimations. It can be data conversion, test environment setup or anything that was not accounted for when estimating.
- One or a few specific tasks were much harder and took much more time than anticipated.
- All tasks are slipping by roughly the same percentage.
- The scope of the project was changed without adjusting the budget.
- Idle time when people cannot work because they are waiting for someone else to finish something they need before they can start.
Estimating Projects
When I estimate a project I try to use methods to remedy the five reasons for disasters. The key activity for me is to create two separate lists.
- A list of all the components that will be required in the system. This is often of the form of a logical view that can be the basis of a architecture document.
- A list of all the things that need to be done in the project, from project startup, through implementation of use cases / user stories to testing and delivery to production.
I then put these into an excel sheet with the components as columns and the things to do as rows. For each row, I do a quick check of what components are affected and put an estimated time in the corresponding box. Having to think of all component-feature combinations both reduces the risk of forgetting things as well as the risk to underestimate the complexity. A complex task will probably involve many components and having to put an estimate on each component often comes up with a sum that is larger than my initial gut feeling.
The remedy for a general slipping with the same percentage is mostly a matter of scaling. With experience and a routine of following up my own estimates I have got my slip factor down from about 150% (the mediocre phase) to about 0%.
Scope changes are not really a problem of the estimator – it is a problem originating at the customer / product owner. My remedy for scope changes is to make sure that there is a brief description of what is included in the project and what is not. That way I can always refer back to a document to point out what I used for estimation. If a requirement isn’t in that document, the estimate does not cover it.
The Idle time is more of a project management issue. A good project manager will make sure that there is alternative activities that people can start with if they are stuck on some task waiting on some external factor.
Conclusion
How did you become a programmer? Through practice of course. It is impossible to become a programmer without practice; just reading books on programming won’t do. The same goes for time estimation. It requires practice to get good at it. There’s no reason to wait, start right now. Before going back to work, set a goal for yourself. When should that task be done? Before lunch? Today? Tomorrow afternoon?
Estimating when things should be done automatically gives you another interesting exercise: defining when things are done. Knowing how you expect things to be when they are done often gives you a clear path how to proceed with your work and often saves you from having many “almost done” tasks on your desk.
Exactly what I was always explaining to fellow developers – perfect article!