In a practical software world, when you’re working on a big project; one of the hardest thing is Software Estimation. Team members generally can’t predict what to estimate from stories. And also PMs (Project Manager) or SMs (Scrum Master) often get confused about estimating and committing. Anyway, since I couldn’t find direct information about this topic, I wanted to share my thoughts about Software Estimation.
What is Estimate
I want to first define to estimate. dictionary.com defines it as:
To form an approximate judgment or opinion regarding the worth, amount, size, weight, etc.
An example of this would be: “This feature will take 2-4 days”, or “Learning curve will be 5-7 days”.
In software world, estimates are made for targets. Targets are basically business needs or desirable objectives to accomplish. As an example, “We need to add product bundling” or “System should support import/export”.
In Software Estimation equation, there is another parameter called: commitment. I think people get confused on this part.
What is Commitment
Again in software world, we can define commitment as:
A commitment is a promise to deliver a certain functionality at a certain time with a certain quality.
Let’s give some examples: “Bundling feature will be in the next release” or “We’ll fix 20 bugs in this iteration”. As you see these are promises that you’re giving and you’re taking responsibility on these promises. When you give these promises, you have to achieve them. This is not an estimation, this is a promise.
Estimation, target and commitment are three different terms and in software world, these are totally different than each other. How do they differ? Well, first of all we can all distinct the target from estimation and commitment. That part is easy, because they’re business needs and they’re not arguable. Estimation part is a measurement and it’s not negotiable. I want to repeat this. It is not NEGOTIABLE. Like if you think someone is estimating the distance between two cities. Basically he is measuring it approximately. Let’s say that he said that “I think it is 200 miles”. At this point, you cannot say “If we push, it would 170 miles, right?” :S As you see it doesn’t even sound good. You cannot argue the measurements. What you can argue is commitments, and they are NEGOTIABLE. So in this particular example, if you say: “You can take this 200 miles in 1 hour, right?” this would be appropriate sentence. But he might say that “No no, maybe in 1 hour and 10 minutes”. This part is negotiation part. We’ll touch that below. At this point you can ask, then why are we estimating if we cannot argue that?
Purpose of Estimation
I’ll quote Steve McConnell here:
The purpose of the software estimation is not to predict a project’s outcome, it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
As you see, it is to help project planning and management. Not to give accurate dates and times.
What to Estimate
We estimate anything that is important for the success of the project like size, time, cost, effort, risk, etc. And again, our estimations are just estimation, not an accurate informations. When I say accuracy, I mean “this task will take 2 days and 24 minutes”. Yes, this is an accurate information. But it does not make any sense for me since in a practical world, this is not an estimation. Below, there is a nice chart (from: Craig Larman) of Uncertainty Cone in an agile development process. As you may notice, if iterative developments are time-boxed (like in Scrum), your uncertainty goes away.
Of course I assume your project has clear requirements, clean and quality code base and a good planning.
One more thing about estimation is, it is an on-going act. When you receive a new information or requirement, estimates should be re-done. Otherwise your project fails. Anyways, I would like to talk a little bit about “how to estimate” and then finish my post.
How to Estimate
First of all, all estimation should be based on historical data/analysis (history of company, history of industry or history of current project etc.). BA/PM or SM should clearly tell what to estimate from business point of view. This includes big chunks of a story that belongs to a target, not the minor ones. Another thing is never estimate alone. This means that when you’re estimating, you should be at least 2 or more developers involved since one person might be wrong. The other thing which is often forgotten is “PLEASE INCLUDE EVERY SINGLE THING RELATED TO YOUR TASK WHILE YOU’RE ESTIMATING” like machine setup, DB arrangements, build time etc.
Of course we can talk a lot about this topic. I want to cut it short. I tried to share my rough thoughts about software estimation. This is a book size topic to discuss. However I wanted to give my experience about it so far. Hope it gives some idea. If you have any thoughts about it, please share with me. I’d like to hear it!
