When you and your pair partner work on your task (PairProgramming, of course), you are accumulating a PairingDebt. If you accumulate too high a PairingDebt, you're artificially lowering the velocity of other members of your team (because they're spending more time helping you than doing their own work). You reduce PairingDebt by pairing on your partner's task. Spending too much time on another's task leads to a PairingSurplus.

High PairingDebt should be avoided as it makes YesterdaysWeather less clear at the individual level. People won't always want to work on your task instead of their own, so your personal velocity is harder to track. Of course, this is only a concern if you are using personal velocities during IterationPlanning.

----
I don't understand. Aren't you as a pair working on a '''joint''' task? What are these ''your task'' and ''his task'' things? -- PeteHardie

''Some XP teams work like that. VanillaXp, however, has an individual sign up for a task. That individual will pair with another person to accomplish that task. During the time taken for the task to get done, the pair may change frequently; indeed, if a task is going to take more than a few hours, the pairs '''should''' change. Depending on the circumstances, the individual who has signed up for the task may not even be part of the pair working on it. In such a case, the individual would be accumulating a PairingDebt twice as fast. -- RobertWatkins''

hmmmm. I think that PairProgramming isn't being used correctly if the task being worked on is in neither of the pair's task list. However, you do have a point about the amount of time spent on one developer's task vs the other of a pair's. I believe this is handled in the claim of better than double productivity from each pair. -- PeteHardie