planning game. And the planning game is when you sit down with the users and scope out on CRC cards, which are a basic premise of XP. You come up with these index cards, and you actually put story pieces on these index cards that you put up on a bulletin board so that everybody can see the extent of the overall system. Even from a regional planning game perspective.
Now, one of the things that's talked a lot about is something called project velocity. And one of the things I found doing a lot of research on Extreme Programming is that Extreme Programming like anything else has its own terminology. It has its own terms, terminology, acronyms. And if you go onto the e-group Web site, you'll find that very quickly you'll start panicking, you'll say, "Gee, I didn't know Ruby was a language, I didn't know this was a language. It's quite interesting." So the project velocity is a ratio that is, it means the team processes, if your velocity rises, if you're doing good in terms of velocity, that means that you're developing things quicker. And all you need to develop velocity is story points done over time. All you need for task tracking this is time-in versus time-to-go for each task. So when you think about this, velocity is really, when you take a look at the ratio of estimated development time and calendar time.
Now, traditionally for a lot of companies that have been tracking metrics, they've been tracking things such as productivity---how many lines of code can somebody develop over time? Well, that doesn't really work, because if you insert somebody to develop lines of code, what are you going to get? More lines of code. What about function points? Would function points work? Which, function points is like the square feet of software. Can we use function points on stories? Well, yeah, we could. We could definitely use it on use cases, we can use it on stories. We can probably do better, though, in tracking the number of changes to a story. How many times did this change in this particular iteration? How many times did we have to refactor code? How many different stories are actually developed? How many times did we have to go and redo tests? That type of thing. There's a lot of different things that we can start taking a look at in the Extreme Programming area.
And I'd like to extend to you, if you're thinking about starting XP or if you are in XP, that we'd like to form a study group on StickyMinds.com, where we'd actually like to have companies who are working with XP, who have started working with it, who have had successes and failures, really have an interaction where we can start focusing on what are the good metrics? What are the things that we should be capturing? Because the traditional metrics, things like defects per line of code, aren't going to have any place when you're taking a look at XP programming.
So we need to take a look at those types of things. We need to take a look at the number of tests that you could run successfully. How many tests did you have to develop? That type of thing. And we really want to focus on business value. A lot of times, Howard Rubin and some of the people that are strong gurus in our industry, have talked about focusing on business value. Well, that's one thing that really gets amplified in Extreme Programming. Because you're sitting