But you have to buy in to XP in order to see the value of User Stores or Tracker.
http://en.wikipedia.org/wiki/User_story
I'm trying to get my head around "buying into XP". At what point do you describe the thing that you're about to build?
I don't believe huge requirements gathering phases, requirement documents, or any heavy weight processes are required. However, I don't know how an engineer can write code without at least being able to fully understand the problem, and then in english, explain the problem and propose a solution.
Often, I find just writing out the bug (and describing how I'm going to solve it) is enough to clarify in my own mind the correct solution. I could do that in my own head, but putting it on "paper" forces me to not skip any steps, and more importantly, provides a paper trail for future developers (or myself) in trying to understand my choices.
So yes, you shouldn't sit down to write code until you think you know what you're building. But XP stories are generally in the range of a few hours to a couple days. And if you are in a typical XP team room [1], you are near colleagues. You will also likely be writing automated tests that document the change you are making. So a paper trail is rarely necessary; conversation generally suffices.
If you need to sketch or write something out to think about the problem, by all means do that. The XP teams I'm familiar with tend to do that by nabbing a couple of colleagues and working through things on a whiteboard that gets erased when a story is done. Some of them do make more permanent documentation if they're afraid of forgetting something. That might happen in code comments, in test comments, or in a project wiki.
On tracker, the comments system is abysmal, so you either end up with a long unreadable conversation (god forbid there be more than 2 people discussing something at once -- thats a nightmare) that noone wants to read, and thus the curated requirements for the story are missing and would take 30-45 minutes to find. OR the comments system is abandoned, and you lose the ability to "track" this part of the process. Epic lose.
Can't wait to see jcooper's work-of-art chrome extension. ;)
I like this balance and aim for brief story titles with descriptions which include the "As a <role>, I want <goal/desire> so that <benefit>" style requirements, implementation concerns, and other acceptance criteria. I could certainly see a place for a more opinionated story writing tool though. Especially for team who struggle to produce actionable stories.
I also see a Tracker story as a placeholder for a conversation which needs to happen. Not as a good tool for mediating that conversation in the story comments and attachments.