November 20, 2009 – 8:18 pm
We are in the throes of development of our product, and while coding marches on, we’re asked on a near-daily basis: when will it be done?
That’s a tricky question, one that has plagued developers and managers for years. There are countless books on how to estimate software development, and it seems everyone has his or her own idea of how it should be done. In my own personal experience, I’ve seen everything from determining the number of lines of code and calculating based on that (part of the CMMI Personal Software Process) to plugging the number of ASP pages in an Excel spreadsheet and ending up with a time based on some arcane calculation.
In my current project, we had to face the specter of determining timelines this week, and without a clear vision of what “complete” means, we have to take things step by step. We had several choices for our estimates.
The first option involved using the traditional time-based estimate. “This will take three hours,” or “I think this will take two days.” This type of estimate is good for determining a stop date for development, and managers like it. However, it can be very inaccurate and put the developers in a position where they have to defend against accusations of failure. Because we’re learning about our vertical market and WPF at the same time, it’s extremely difficult for us to get any accuracy on time and date estimation.
When I was at HP, we used a “level of effort” estimation. The first iteration for the LOE was 150%. In other words, the project’s timeline would be met somewhere between –150% and +150% of the initial estimate. So if we said 10 days, it could be done as late as 25 days (-5 days wasn’t really an option). In the second iteration, we reduced it to 50% LOE, and then finalized on 30%. In a big project, a 30% LOE can be a huge variance. Consider a project with dozens of developers and thousands of hours of work. A 30% LOE on a 14,000 hour project is 18,200 hours. If you’re paying by the hour, ouch.
The second option we looked at was the one we went with: relative sizing. Rather than evaluate a task in terms of how long it would take, we looked at how difficult it was. Each task is given a number based on the Fibonacci sequence (1, 2, 3, 5, 8…). A “1” is very simple. A “2” could be more complicated, but still pretty easy. And so on, until you reach the upper numbers, which imply that the task is extremely difficult and should be further broken down.
We looked at one of our key deliverables and broke it down into a couple dozen tasks. Then we got together as a group and sized each task. Creating a screen might be a 2, while developing its databinding is a 3. We wrote down each task on a sticky note and put it on our board. Each week, we go through the tasks and choose the ones that will be “on deck” for that week, and put the rest in the backlog. The developers then assign themselves tasks, one at a time, based on the difficulty of the task and their comfort level with it.
One of the nice effects of using this technique is that upper management (including myself) can look at the board and get an idea of what’s going on at any given time. Each task’s progress is also tracked in our daily scrum reports, which are logged online. If a developer needs help due to a roadblock, he makes a note in the scrum report and we figure out how to solve it.
At the end of each week, we look at the results of the sprint and decide if our estimation of what we could complete is accurate, and we adjust the following week’s tasks accordingly. This is called establishing velocity. We are able to determine what our work product is from week to week, and make a determination on how long something will take by looking at evidence from previous sprints. If Developer A takes an hour on average to complete a 1, and three hours for a 2, then we can determine that within a 30 hour productive cycle that he can do 30 1s or 10 2s, for example. It’s not supposed to be that precise, but rather give us an idea of what we can expect.
We’re young with this process, but I feel confident about it. I need to be able to respond quickly to removing roadblocks for the developers while also producing my own work output. By viewing the board, I see what is going to be done, and by participating in the board, I set the expectation for my own work.
In my next post, I’ll discuss hierarchies of the individuals involved and how interaction works between them.
Posted in Enterprise | No Comments »