Estimating Software Development Tasks Made (a little bit) Easier

In my career to-date I’ve had the enjoyable task of estimating a lot of software development projects. This blog post details a technique I’ve devised that makes structuring and risk assessing software estimates a little easier.

##Estimating software is difficult! I’m sure that other developers who have had the pleasure of estimating software would agree that it can be a very difficult task. Estimating a project comes attached with fear of inaccuracy, pressure from project managers to underestimate (or overestimate depending on company ethics) and the expectation that you can answer in less than 5 minutes as standard.

A lot of estimating is based on gut feeling and experience. It’s likely you will never be asked to estimate the exact same thing twice so experience, whilst essential will still not result in bullet proof estimates. The problem with the gut feeling aspect is that it can be very difficult to communicate your hunch to your colleagues and sometimes difficult to convince even yourself.

##Structuring your software estimates What I’m about to share is my own personal method of gathering my own thoughts and estimates in a way that I can communicate easily with others and enable me to factor in elements of risk, or in layman’s terms - to cover my backside!

It’s a simple approach and definitely not a silver bullet, however using a simple approach when faced with a complex task is how I like to do things. The approach is based around the following principle: you will make mistakes with your estimates. With this in mind, how does one provide accurate estimates knowing they are going to be wrong? Answer: try to reduce the risk as much as possible.

##The Simple Steps ###Step #1 - Breakdown the work into line items Try to break down the project into single line items under logical section headings. Name each line item so that it would make sense if you took it as a task and moved it into a tracking tool such as Fogbugz.

“Set label text to ‘first name’” might be a little too granular but something like “customer sign up functionality” is probably too open ended. The below example shows how you might start off with the open ended task as the group heading and evolve this into workable units.

Task: customer sign up functionality

• design html & css
• create new asp.net page
• add javascript validation
• create new presenter with SignUp method
• create new database table

###Step #2 - Only estimate in hours Each line should have an estimate that is more than 3 hours but less than 16 hours. I try to aim for 8 or less however this isn’t always practical for larger tasks or if you have limited time. If an estimate for a line item is greater than 16 hours it probably means the line item is too open ended and needs to be broken down further. Here is how the previously used line items might look:

###Step #3 - Score each line item based on risk For each line item I would attach a score based on risk. If it’s a very simple task I would flag as “small”, medium would be “medium” and “large” would of course be a large risk. A large risk would usually be an area in which I have limited knowledge or if it’s for a familiar system it would be something where I expected to hit problems. Such problems could be changing part of a system I know has been poorly designed that would make changes difficult. Small would indicate I’m 90% confident this task will take as long as I’ve specified because I know the area well enough.

Each risk has a percentage value as follows:

You could break this down further into Extra Small, Small, Medium, Large, Extra Large for more precision is needed.

Here is how the line items would now look:

###Step #4 - Try not to look at the running total It’s very important to try not to look ahead at the overall time building up as part of your estimate. Seeing the overall figure building up may influence your estimate for the next line item. There will be occasions when you will be shocked at the end result if you wait until you’ve broken out each line item until you calculate the overall estimate.

##Number crunching Now that you have built up your list of line items with attached risk we need to draw some conclusions from the data. The most sensible first stage would be to sum the total hours:

Total hours: 38 (sum of all hours)

We can now add up all of the risk scores to calculate an average risk:

Average risk: 305 / 4 = 76.25% (sum of risk / no. of line items)

As you can see, we have estimated a 76.25% risk against for the project on average. We can now use this figure to draw best case and worst case scenarios using these calculations:

Best case: 29 hours (total hours * (avg risk / 100))

Worst case: 50 hours (total hours * (1 / (avg risk / 100)))

Using all of these calculations we can now average out against the worse/best case scenario. Our final estimate for the project would be:

Average: 40 hours (best case + worst case / 2)

The end result would look something like this:

This is a very simple example of course, but it should be enough to convey the process. I would typically put this data together in a spread sheet and present my estimates with associated risk to the decision makers within the company. If you are challenged on your estimates or another developer were to review your estimates they can clearly understand your decision making.

On some projects another developer and I have both drawn up our own spread sheets using this process and only compared data once we were done. The results are very interesting and generally result in very accurate estimates. A “Small” vs. a “High” score for the same line item will quickly help to narrow down the grey areas.

##Knowing if you were right The final step in estimating is to track the actual project progression against your estimates. Knowing if you are an optimistic under estimator or a cautious over estimator is essential in refining your technique and honing your gut instinct. Being an under estimator could cost your company money and by contrast over estimating may price your company out of the market place. These stats will likely be public amongst your peers and will no doubt place you under the spot light but if you’ve communicated your reasoning correctly and identified the necessary risk areas you should be half way to success.

##What about agile? I’ve worked exclusively in private enterprise and thus my experiences are shaped by this, however I’ve yet to work on a project that uses a pure agile approach when it comes down to money. I think it’s a sensible question for a client to ask how much something will cost and what they can expect for their money. The concept of releasing early and often is wonderful but before you can even get to this stage it would be common to have some form of contractual agreement in place based on an estimate - a software estimate that was created by you!