We’ve been switching pairs a lot in an effort to try to share knowledge between team members before and it’s been working really well. The downside to it though is that since the team owns the tasks and people swap between tasks so much (which is what gives the shared knowledge), there’s always the danger that you will get off track and start wasting time writing code that isn’t actually needed for the user story.

That’s where acceptance tests should help out. You should be able to sit down to work on a story and decide to work on getting a specific acceptance test to pass. List out the steps required for that acceptance test and then start working on them. If you wind up changing pairs before the acceptance test passes, leave the todo list with whoever picks up the task and they will know where to pick up from. The new pair should still check that the tasks you’ve listed make progress towards the acceptance test. In true XP style the hand-over is a conversation between the old pair and the new pair explaining what they were doing and why.

None of that of course precludes one person from the old pair staying with the task – indeed it’s much better if you only switch out one person from the task at a time, but the hand-over and acceptance tests are still beneficial just as a sanity check to make sure you’re on track.

So acceptance tests do more than just tell you when you’re done, they also tell you where you’re going, where you’re up to and what you should do next. We need to get more disciplined and write acceptance tests up front so that we can use them as our roadmap while we work. Get back to the acceptance driven development we had going when we first starting with XP.