10 ms·

There's a pretty long answer to that question. User stories are a critical piece of XP (eXtreme Programming), and Tracker is a project management tool targeted

There's a pretty long answer to that question. User stories are a critical piece of XP (eXtreme Programming), and Tracker is a project management tool targeted directly at XP teams. But you have to buy in to XP in order to see the value of User Stores or Tracker.

nupark2 15y ago
Fair enough. Reading this: http://en.wikipedia.org/wiki/User_story 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.
- wpietri 15y ago
  In XP, every user story (often known as a "card", because XP teams often track them on index cards) is a token for a conversation. 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. [1] http://www.scissor.com/resources/teamroom/ http://www.scissor.com/resources/teamroom/
- apolzon 15y ago
  The piece thats missing for me with tracker is the conversation. As atomical points out, there are times where you want the story to have some vaguer requirements to allow it to breathe and evolve on its own. During times like these, it grows through the conversation and chair-spin between developers, product owners, etc. 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. ;)
  - zalambar 15y ago
    I see Tracker as a prioritization tool first and a way to capture stories second. It is highly opinionated about and focused on prioritization but leaves the details of story writing and the conversations apolzon is looking for up to you. 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.

nupark2 15y ago

Fair enough. Reading this: http://en.wikipedia.org/wiki/User_story 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.

wpietri 15y ago
In XP, every user story (often known as a "card", because XP teams often track them on index cards) is a token for a conversation. 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. [1] http://www.scissor.com/resources/teamroom/ http://www.scissor.com/resources/teamroom/
apolzon 15y ago
The piece thats missing for me with tracker is the conversation. As atomical points out, there are times where you want the story to have some vaguer requirements to allow it to breathe and evolve on its own. During times like these, it grows through the conversation and chair-spin between developers, product owners, etc. 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. ;)
- zalambar 15y ago
  I see Tracker as a prioritization tool first and a way to capture stories second. It is highly opinionated about and focused on prioritization but leaves the details of story writing and the conversations apolzon is looking for up to you. 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.