A very crucial part of software projects is the estimation. It takes place in the early stages of development, be that sequential or iterative. The goal of estimation is to predict certain aspects of the planned system. How big is it gonna be? How much effort is required? How much will it cost? (This is the number one). As software developers, it is our job to provide as accurate estimates as possible.
Why is estimation important?
Why should we aim at providing better estimates? There are a couple of reasons:
Better quality: With accurate estimates, the appropriate time is allocated to development, that reduces stress, which improves quality.
Better budgeting: This is kind of self-explanatory, with better estimates, we have a better understanding of the costs involved.
Early risk information: Let's say you are given a specification and they ask you to finish it in two months. You do your estimation and turns out, it's gonna take four months at least. This is great! You've identified a mismatch between the requirements and the schedule before development even began. Now you can work this out with the customer. What is the most important? That the functionality is done by a certain date? If so, what non-critical parts needs to be removed so the deadline could be met?
Imagine if the estimation is done poorly, and you would think the 2 months schedule is feasible, but it actually would require twice as much? Some parts would be cut, others would be rushed resulting in poor quality and a disappointed customer.
I'm gonna give a few tips on how to quickly improve your estimates, but first I need to discuss the difference between estimates and commitments.
Estimate, Target, Commitment
When I was asked to give an estimate, to my surprise, that number was handled as if it was set in stone. Once given that is what we would bill the customer, regardless whether we finished sooner or later. The reason for the confusion was that they wanted a commitment, not an estimate. An estimate is a prediction, on the scope of the functionality. A commitment is a promise to deliver the functionality by a certain date. A target is a desirable business objective.
Now it's clear to me what the customer wanted. They needed a commitment within their targets.
If you only have a couple of hours to make your estimate, consider the following tips.
Count & Compute
Find something that you can count.
For example, I had to estimate a file validation process. It involved a series of tests the file had to pass since the individual tests were similar in difficulty, I used them as a counter, this way I only needed to estimate the average time it would take to complete a test, and multiply with the number of tests to get the final value.
Break it down
Break down the tasks into small chunks: 4 hours, 8 hours, but no bigger than 2 days each. It's easier to measure a small task than a big one.
Another great advantage of this comes from the probability principle: Law of Large Numbers. In our case, this means, that some tasks will be overestimated, and some will be underestimated. These cancel each out somewhat, and the final error will be less. If we give one big estimate, there is no such error reduction.
Use ranges
When you say the report page is gonna take 4 days to develop, what does it mean? You are absolutely certain it cannot be ready sooner, nor will it take longer? Probably not. For this reason, it is better to give ranges instead of single point estimates.
Consider the best case scenario, it might be 2 days if all go well. What if everything goes wrong? 10 days could be the worst case.
So now we have a 2-10 days range. Remember we need to provide a commitment, not an estimate. The commitment has to be a single number. How many days should we say?
One way to go about it is the Program Evaluation and Review Technique (PERT) formula, which is as follows:
Expected case = [BestCase + (4 x MostLikelyCase) + WorstCase] / 6
So in our case it is : (2 + (4 x 4) + 10) / 6 = 4.66 =~ 5 days.
Don't give estimates on the spot
Sometimes you might be pushed into a situation where you are asked to give a rough estimate on the meeting, the hallway etc. Don't do that. Tell them you need to measure the task properly before you can say anything. The reason for this, that 'on the spot' guesses are highly inaccurate. So you say it might roughly be a day to migrate the system to the new server. Then once you go through a proper analysis, you conclude it's gonna take more than a week. Now it's a lot harder to settle on your new estimate since you said a day the first time. If you say nothing at first, then it doesn't create a false scope people expect the task to be in.
Match the estimate's precision to its accuracy
Accuracy refers to how close to the real value a number is. Precision refers to how exact a number is.
What this means in practice is if your calculations end up with 62.4 days, you shouldn't say 62.4 days, it might be precise but unless you actually end up with 62.4 days, it won't be accurate. On the other hand, if you say 2 months and you finish in 68 days, which is still rounded up as 2 months, your estimation is accurate. This is critical when providing the final number to the customer.
T-shirt sizing
In this practice, each feature would get assigned a size like with T-shirts: Small, Medium, Large. This is done both by developers regarding the features size and difficulty, and also by the customers, stakeholders regarding its business value.
Used in the early stages of development, this is an incredible tool to see what feature should the team focus on.
Summary
- Make sure you understand the requirements before you begin estimating.
- Use T-shirt sizing to determine what features to focus on.
- Find something to count in the system, and base your estimation on those, guessing should be a last resort.
- Use ranges with estimation, but single numbers for commitment.
- Match the precision to the accuracy of your estimate.
For further information I recommend Software Estimation: Demystifying the Black Art by Steve McConnell. The are more practices described in it: using Standard Deviation to get % confident estimates, Estimating with story points, Using data from previous and the current project to compute your errors, and tweaking the formulas to get more accuracy, and a lot more.
For the long run, I strongly recommend to try out these practices and see what works for you.
I hope this was helpful to you. If you have any questions, leave a comment below.
Have a wonderful day!