Estimating Software Development Tasks Made (a little bit) Easier

how to plan your next software estimate
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:

SectionLine Item Estimate in hours
customer sign up functionalitydesign html & css 12
create new asp.net page 4
add javascript validation 6

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:

Key Confidence of accuracy
SMALL 90%
MEDIUM 75%
LARGE 50%

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:

SectionLine Item Estimate Risk
customer sign up functionalitydesign html & css 12 MEDIUM
create new asp.net page 4 SMALL
add javascript validation 6 SMALL
post sign up details to 3rd party API 16 LARGE

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:

SectionLine Item Estimate Risk
customer sign up functionalitydesign html & css 12 MEDIUM
create new asp.net page 4 SMALL
add javascript validation 6 SMALL
post sign up details to 3rd party API 16 LARGE
Total38MEDIUM (76.25%)
Best29
Worst50
Avg40

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!

2 comments:

  1. Hi Brad,

    I don't think you'll ever work on a project that is pure Agile - the best you can get to is to work on a silo project that exclusively uses Agile, but uses waterfall when communicating with other departments.

    By the way, I would really like to publish your post on PM Hut, where many project managers will benefit from it. Please contact me through the contact us form on the PM Hut website in case you're OK with this.

    ReplyDelete
  2. I think agile is easier to pull off with internal projects or products! Open ended deliverables and time frames can only work where the main stakeholder has an open ended approach to finances!

    Feel free to publish the post but please ensure it credits the original author.

    ReplyDelete