Measurement and estimation context
Before starting to get into technical details, I’d like to clarify what is the purpose of all this and where it fits into the development process. It’s a vast topic and I won’t pretend to cover it all. I am restricted by the context I have used it in. I don’t plan on reformulating books in here.
Estimates can be made at multiple level. The estimate you give your client is most likely not going to be the same as the one you use to track your progress, simply because the objectives are not the same. Your own estimates are meant to be honest and try to be as accurate as possible. The end result is as likely to be above or under the target value. The one you give to a client is usually supposed to be a ceiling type of estimate. Clients don’t like to see the price going up and you don’t like loosing money for underestimating.
I don’t perform estimates for clients. I use them to track my own development and communicate. The process of estimating provides numbers about the development that can be used to track the progress of the project. If you know the total size of the project and know how much you have done, you can obtain a nice metric called earned value. Ever heard of a project at 90% completion for months? Tracking earned value is a good way to avoid this problem as you can find out at all time what is the exact completion percentage of the project. Combined with the percentage of used time over the total estimate, it can indicate if you project will be early or late long before the deadline is reached.
Managers have their own scheddules. They make their estimates based on various criterias. In the best cases, they will ask the developers for their own estimates. Since all those MS Project files are long to update, being able to give a warning a few weeks in advance that the project will take longer or shorter than originally planned can be useful. As a developer, you might get to have the feeling something is going wrong and the project will end up being late. It’s possible to support this feeling with facts.
Even if there is no money envolved, estimates help anticipate problems. Using half an hour to perform an estimate before the project starts and a few verifications during the development provides insights that can be very valuable.
The estimates can be performed on complete projects or smaller tasks. It’s probably a good idea to start training on smaller tasks. They provide data much faster and allow to adjust the process to your specific needs. There is no ultimate way to do these things. If there was, it would probably be supported by all development environments and there would be no need to write about it. Measurement techniques has to be tailored, collected data has to be selected and observed metrics must be identified. The process might seem complex, but it’s actually very simple to perform, and this series of post aims to give a practical aspect to all those academic terms.
Academics tend to generalise measurements and estimation processes to become organisation-wide. I have the feeling it makes no sense. In the end, each developer has to perform the work seriously. The results can be aggregated for work teams, but I doubt it can go far beyond that. It’s useless to measure something you don’t need. If the measurement requirements are organisation-wide, chances are you will have to measure for everyone’s need, which can be a lot of measurement. Too much measurement is time consuming. If you don’t know what the idea behind it is, it’s hard to take it seriously. I will discuss the limitations of measurement once I have covered more specific aspects. For now, keep in mind that it’s better to start locally and focus on direct results.
The techniques I will present apply to the developer’s own development process. Now that the context is set, I can begin writing about some technical and practical aspects. In the next post of this series, I will cover the size measurement.