How are you estimating development costs?

If you are charging money for software development you either have been or are going to be in trouble for it. There is a model that I use to explain how FlexDev projects are priced, which I’ve found the hard way. Feel free to use it (reference appreciated). Or tell us what can be improved.

First a list of what the model should do:

• make the costs transparent to the client (where does the money go)
• predict velocity
• quantify how much work remains

If you have a modern car, it has a displays that tells you:

• how much fuel is used for 100km on average and right now
• how fast you’re going on average and right now
• what distance you can go on the current tank of gas

If you have a gps navigation system, it tells you how much time and distance you have to go to the destination. I want to give clients the overview they have in their cars, translated to software development.

What’s the mileage

With a car you know the mileage (or the kilometrage if you’re not scared of SI). Software development is different in some ways, but usually if you have a team on familiar ground it is surprisingly easy to teach them to estimate well. Just as long as you give the right feedback. SCRUM traditionally computes velocity, but for us that’s not enough, because Squad.com teams are working on several projects with fluctuating budgets. At different velocities your mileage may vary – like in a car.

With cars, even if you know the mileage on a typical road at 120 km/h, you still don’t know the mileage on your particular trip. If you’re planning a rally through the mountains, or to pick up kids for a party, you should expect a more wasteful trip. If you know how much a development team can do on a certain stack you can predict the mileage on that stack. But doing it for different stacks and problem areas is tricky. Make sure you have a way to measure the current mileage and the running average for each project.

But what is a liter of fuel, or a kilometer in this analogy?

At FlexDev we measure capacity. You can buy capacity with money. Capacity is decoupled from hours: one of my hours spent on Scala is very different from one of my hours spent on CSS3. The generic term capacity is a facade for process of involving the right people in each task. If that process goes well, we might get to take a day off, or make some extra profit. If that process goes bad, we work in the weekend.

We measure progress in complexity points, estimated based on experience and understanding of the work that needs to be done. Estimating is hard, but there are some tricks that you can use to get into the right mode. More on that later.

Once you work on estimated work for a while, it becomes relatively easy to calculate the mileage.

What is our velocity

Velocity is complexity points per time frame. Like with a car, it is possible to go slow and fast by using the throttle (set a weekly budget). This has an effect on the mileage. Each car has an optimal velocity; teams are similar. Other than with cars with teams there is a lot of things you can alter in the team behavior to adapt to a different velocity. The trick is to get optimal mileage at high velocity and then keep the velocity high.

When a the client wants to make sudden turns, or slows down decisions the mileage suffers. Just as it would with a car when decelerating quickly. With a car analogy, it becomes easier to explain that  if we’d just make up our mind together we could get more bang for the buck. That doesn’t mean that driving with poor mileage is always the best strategy. Sometimes you should be burning rubber, and damn the costs. We should also estimate what efficiency is the most effective for the business.

How to estimate

At some point you have to baseline the meaning of a complexity point. Typically in SCRUM this happens by choosing a reference story and setting it at an arbitrary value. Let’s say 3 points. Then you estimate everything against that. Theory is that if the team gets faster, they keep assigning the same points to similar stories. In that way you can detect changes in velocity.

There are some tricky side effects to this. The most obvious one is that as you learn, the implementation strategy will change. Meaning that later in the game, you’d pick a different solution to a problem, probably making the problem less complex. Solved differently the problem will get less complexity points, and more importantly, it’s relative complexity to other stories might change.

Another way I often use is to norm against how much time you think it would take. This is frowned upon in the Agile community, but in the end, I’d rather know what my costs are going to be than have a historic record of the velocity changes within projects and teams. Problem with this is that if a developer says 1 hour, it means he can do about 4 of those tasks per day. If he says 8 hours he cannot do two of those tasks in 3 days. The reason for this is that creative work doesn’t happen linearly like the production of minced meat. The relationship between input and result is more decoupled – like with marketing, or planting seeds. This process differs between tasks, so it’s hard to model.

To cut this short, I’ve come up with a strange mind game that seems to work well. I ask the estimators to imagine a perfect day. They’re pair programming. No disturbances. Immediate answers to clarifying questions. Then I ask them how many of these tasks they could do in that perfect day. A perfect day is 20 complexity points. So if the answer is 4, the complexity is 5. If the answer is 7 or 8 the complexity is 3 if the answer is 10, the complexity is 2. You get the point.

After doing that for about 10 minutes, I never mention the perfect day again. I never norm again. I just let it slide and measure. It’s totally unscientific but it works better than everything else I’ve tried. Now our last task is to get the client on board. Estimations are not quotes, and treating them like it will lead to disputes.

Message to your client

Our team is like a car. You can buy capacity at X money / capacity unit. On average we do Y complexity points/ capacity unit. Your project is estimated at Z complexity points, so we calculated the cost at …. Your mileage may vary.

Simple isn’t it. We work in weekly iterations, allowing bidirectional feedback to flow between client and team. It the client is unhappy, we explain and offer a refund of the last week in the worst case. But usually clients have somewhere to go; they don’t step out of the car half way because of the mileage being different. Managing expectations continuously helps prevent an expectation debt; it makes for easier conversations about scope creep, budget creep and delays. This model incidentally also explains very well why we charge money up-front. If you don’t put fuel in in the car, you will get stranded in the middle of nowhere. You should fill her up before you go.

Most elements of this model have been invented by other people, much smarter than me. This is just the way we roll. What’s yours?