Xp Planning Terminology

This is from our book work in progress. I hope this makes things clear. If it doesn't let us know - we'd rather know about problems earlier.

MartinFowler (while writing an XP planning book with KentBeck)

Any sufficiently self-important computer pundit generates lots of new words. These new words work best when they sound familiar yet clearly have meanings that are beyond the average person and only truly understood by those in the know. Such well-educated individuals can drop these terms into the conversation in such a way as to confuse the unwashed. This is important because it builds up a sense of superiority over the uninitiated which makes up for all the effort spent in learning the words in the first place.

You may think we are criticizing this practice but we aren’t. We want to feel superior too.

Calendar time is the familiar passage of time, modified to handle working days. So if you are working Mondays to Fridays then four calendar weeks is equal to 20 calendar days.

Calendar effort is amount of people times calendar time. So a team of six people has 30 calendar development days of effort available per calendar week. In four weeks they would have 24 calendar development weeks of effort available. If one person on the team worked half time, they would have 22 calendar development weeks of effort available in that same four week period.

Most people measure all tasks in terms of calendar effort. This makes sense because it’s easy to measure. However it makes estimating harder. The key to estimating is to consider people working at a reasonable sense of efficiency. Typically this means they don’t get interrupted and distracted by the typical distractions that affect everyone all the time. These even out over the long haul but can have a big effect in short periods of a week or two. As such they really make a mess of historical data that is the backbone of a good estimation system.

So in XP we come up with a second kind of time: ideal time. Ideal time is time without interruption, where you can concentrate on your work and you feel fully productive. We measure and estimate using ideal time, because that allows us to compare tasks without worrying about interruptions. If we look at a task and see it is about as complicated as one that took 2 ideal days last week, we can estimate it will take two ideal days this week. The elapsed time could well be very different, but that is something we monitor separately.

We often speak of ideal time, but really it’s ideal effort. A team of six people might have 10 ideal development days of effort available a week. Typically when people talk of task lengths they say “that’ll take 3 ideal days”. What they really mean is that it will take “three ideal development days”, but that’s too much of a mouthful.

Closely connected with these terms are velocity and load factor. The velocity of a team is how many ideal weeks of effort are available in an iteration. So we might say that a team has a velocity of 8 ideal weeks. That means that in one iteration the team has 8 ideal development weeks of effort available for carrying out its work.

We also use velocity for individual developers. We might say that one programmer has a velocity of 10 ideal days. That means that that programmer can sign up for 10 ideal days of work in each iteration. Most developers will have the same velocity. However if someone is working part time, or is new to the team they will have a lower velocity.

If you’ve read some older stuff on XP you’ll come across the term load factor. Load factor is the ratio of the calendar effort in an iteration and the velocity. So a team with 5 people using four week iterations has 20 elapsed programming weeks per iteration. If it’s velocity is 8 then it has a load factor of 2.5 (20/8). We used to use load factor a lot in planning, but since learned that it’s easier to just use velocity, so now we don’t use load factor any more.

The notion of ideal time has really little to do with time. Indeed some people like to use something like story points, task points or gummy bears to measure the effort for stories and tasks. This works since the only important thing is that you have the same unit for the actual stories you measured in the past as you use for your estimates.

Velocity is far better than load factor. "Game" should be dropped. ReleasePlanning is good. MilestonePlanning? is one term we've used which seems more general in that it emphasizes synchronization with other things other than software releases. But as Wittgenstein and HumptyDumpty both said in their separate ways: these things get their meaning from how they are used. ReleasePlanning feels good enough to me. -- RichardDrake.

I agree with the definitions of velocity and load factor but it's not clear how you can only use velocity as defined above "the ideal weeks of effort available in an iteration". Isn't there value in understanding how each iteration is approaching its velocity of 1 (ideal weeks/actual weeks). I use the velocity to determine how close we are to removing the distractions of a working day from a developer. It essentially becomes a measure of efficiency. -- Bryan Campbell