In software, one thing is certain — estimates never match reality. Teams build predictable schedules by creating buffers. There are two strategies to do this: 1) by forecasting how much buffer the team needs 2) by computing buffer based on past performance.

Velocity is a way compute how much real time it takes to complete estimated time.

So if I say something will take me 4 hours to build and it takes me two days to complete, my velocity would be 2h/day. That’s useful for future planning because the team knows my capacity (2hr x 5days = 10 estimated hours / week).

A velocity measurement doesn’t say how hard I worked or how much time I spent on the task. It’s merely a calibration tool for effective planning.

My 4 hour estimate (that took two days) from the above example might of seemed awfully optimistic. But that’s not how to see it. I could of ran into an unforeseen complexity, faced an unusually large meeting load, or could have been bogged down with operational issues. Or it might be true, I might just be an optimistic estimator, but with velocity that’s okay. It all averages out.

Teams will also come together to estimate entire features this way. They might estimate how long the feature will take in days. But again, estimated time never equals actual calendar time. So if it takes the team estimates a feature to take 1 day, and it ends up taking 2 days to complete, their velocity would be 2.5 estimated days / week.

Here’s where it gets tricky and controversial…

To get better at estimating when using velocity means getting more precise rather than accurate.

Teams who are good at estimating with velocity will normalize on an inaccurate, but precise value, rather than try to get more accurate. The consequence is that each team (or person) will have their own, unique velocity. Some teams will estimate conservatively and others will estimate optimistically. It is meaningless to compare from team to team or location to location. It just doesn’t make sense. In fact, the moment you start judging teams on ‘improving’ their velocity, their estimates just become more conservative. (Thereby increasing their velocity.)

Some teams have a difficult time using velocity. This is because when a team settles down on a velocity, they question themselves (or get questioned) if it’s not 8 hours of estimated work a day. “How come you’re only planning for 5 hours of work a day! What’s wrong?” (One of the most productive teams I’ve worked with averaged 2hr estimated / person / day!)

Use velocity, but keep in mind that a team’s velocity can’t be compared with other teams. So keep the velocity numbers within the team. If you must report your estimates externally, either take the time to explain velocity or normalize your estimates into real time. Better yet, translate your estimates into dollar (or rupee) values (talk with your finance person to work out some numbers).

Last year (31st, May 2007) I interviewed the Yahoo! Web Messenger team. They were one of the first teams I helped to coach at Yahoo!. During that interview we discussed their use of Continuous Integration. This is a transcript of that discussion. It didn’t take a lot to get them talking.

Me: So tell me about the continuous integration system.

Ben: We fought it for so long… and we’ve finally given in. And it’s the greatest thing ever.

Henri: We originally thought: “We build our stuff, it works. Why do we need something so complicated?” But it’s actually really really nice. We miss it a lot when we don’t have it. When we have check-ins that don’t get built right away, we don’t know if it’s working or not… it kind of hurts.

Mark: What’s really amazing is that every time the build machine process breaks for a day, it’s always the cause of trauma. A bug gets in! You would think it was coincidence if it wasn’t so regular. [laughs]

It’s unbelievable… The one day that the build machine breaks (and say there has been five check-ins) — now we don’t know which one broke this feature! “Ahhggg! if only the build machine were here, that way we would know if it was my check in, or your check in.” Every time [the continuous build system breaks] something like that happens!

It’s just proof that, without it, we would be constantly be saying, “how the hell did this bug show up? Whose fault is this? Is this my fault? I don’t even know?”

Ben: It has saved us an incredible amount of time — much more time than we have ever put in.

Mark: It [the continuous integration system] is a lot of heartache. We will say that. It’s great. We’ll agree. Anyone should know that they have to believe that there will be this big payoff because it consumes time every week to keep it going.

Jon: We had this bizarre bug where the emoticons were appearing off to the side. They were right on the contact list after you scroll. Nobody had this except Stephanie (a product manager). So we talked about it and I looked at it. And she was able to track it down through the build machine — where it did start to happen and where it didn’t start to happen. [She narrowed it down to] between two builds. And we had this one minor check-in where we added a drop shadow to the conversation list. We were like, there is no way that this could be the problem. But, low and behold, we removed the drop shadow and the problem was completely fixed. Because we had the [build] machine, we were able to track down where this bug was.

Mark: Here’s another big thing that people don’t appreciate until you get it: It means that everyone is always using the latest build — and the latest build changes. So Stephanie goes to lunch and logs back in. She’s using the latest build. And bugs are caught really fast. And features are checked in really fast. We knew the last part (features checked in fast), but we didn’t think of the first part (using the latest build).

Stephanie might say: “Oh! I’ve got icons now!” (Or later when getting a new build) “oh… the icons are not in the right spot.” [I would follow up] “Can you go back a build?” [Therefore,] I might find out that day that I broke something.

There isn’t such thing as a broken build. Because of the automatic continuous build integration system with email announcements, no build stays broken. That’s really a big deal. There isn’t such thing as a broken build. Other than the build broke for a moment, so [therefore] somebody is going to fix it. We all know something has happened because we all get the email. We can usually see from the change list who is responsible.

Word.

Continuous integration (CI) is a great ‘tool’ for software development. But the best CI tool installation doesn’t mean that your team is practicing CI. The goal of continuously integrating software is to keep the product working at all times so that a broken system can be discovered and fixed quickly.

In order to achieve this goal, tests demonstrate a working system and the team frequently communicates changes.

When a team starts out on CI, the first step is usually to install a tool. Usually someone is really excited about the prospect of working software all the time. He or she installs or writes a tool to help make it happen. Once it’s all up and running this happens:

All failing…

Honestly, it’s a great first step. But the kernel of a healthy continuous integration system is establishing a team protocol and discipline. The difficult part of CI isn’t the tool, it’s the practice.