Question

As a lead developer I often get handed specifications for a new project, and get asked how long it’ll take to complete the programming side of the work involved, in terms of hours.

I was just wondering how other developers calculate these times accurately?

Thanks!

Oh and I hope this isn’t considered as a argumentitive question, I’m just interested in finding the best technique!

Answer 1

Estimation is often considered a black art, but it’s actually much more manageable than people think.

At Inntec, we do contract software development, most if which involves working against a fixed cost. If our estimates were constantly way off, we would be out of business in no time.

But we’ve been in business for 15 years and we’re profitable, so clearly this whole estimation thing is solvable.

Getting Started

Most people who insist that estimation is impossible are making wild guesses. That can work sporadically for the smallest projects, but it definitely does not scale. To get consistent accuracy, you need a systematic approach.

Years ago, my mentor told me what worked for him. It’s a lot like Joel Spolsky’s old estimation method, which you can read about here: Joel on Estimation. This is a simple, low-tech approach, and it works great for small teams. It may break down or require modification for larger teams, where communication and process overhead start to take up a significant percent of each developer’s time.

In a nutshell, I use a spreadsheet to break the project down into small (less than 8 hour) chunks, taking into account everything from testing to communication to documentation. At the end I add in a 20% multiplier for unexpected items and bugs (which we have to fix for free for 30 days).

It is very hard to hold someone to an estimate that they had no part in devising. Some people like to have the whole team estimate each item and go with the highest number. I would say that at the very least, you should make pessimistic estimates and give your team a chance to speak up if they think you’re off.

Learning and Improving

You need feedback to improve. That means tracking the actual hours you spend so that you can make a comparison and tune your estimation sense.

Right now at Inntec, before we start work on a big project, the spreadsheet line items become sticky notes on our kanban board, and the project manager tracks progress on them every day. Any time we go over or have an item we didn’t consider, that goes up as a tiny red sticky, and it also goes into our burn-down report. Those two tools together provide invaluable feedback to the whole team.

Here’s a pic of a typical kanban board, about halfway through a small project.

You might not be able to read the column headers, but they say Backlog, Brian, Keith, and Done. The backlog is broken down by groups (admin area, etc), and the developers have a column that shows the item(s) they’re working on.

If you could look closely, all those notes have the estimated number of hours on them, and the ones in my column, if you were to add them up, should equal around 8, since that’s how many hours are in my work day. It’s unusual to have four in one day. Keith’s column is empty, so he was probably out on this day.

If you have no idea what I’m talking about re: stand-up meetings, scrum, burn-down reports, etc then take a look at the scrum methodology. We don’t follow it to the letter, but it has some great ideas not only for doing estimations, but for learning how to predict when your project will ship as new work is added and estimates are missed or met or exceeded (it does happen). You can look at this awesome tool called a burn-down report and say: we can indeed ship in one month, and let’s look at our burn-down report to decide which features we’re cutting.

FogBugz has something called Evidence-Based Scheduling which might be an easier, more automated way of getting the benefits I described above. Right now I am trying it out on a small project that starts in a few weeks. It has a built-in burn down report and it adapts to your scheduling inaccuracies, so that could be quite powerful.

Update: Just a quick note. A few years have passed, but so far I think everything in this post still holds up today. I updated it to use the word kanban, since the image above is actually a kanban board.