views:

204

answers:

5

So if a user story is a something nebulous like:

As a sales rep, I would like to capture the contact information so that I can follow up later on.

I'm not even sure if that's a valid user story but I'm sure it's close enough.

Then there are details/tasks for implementing that user story. And I'm sure "The sales rep should be able to tab from one textbox to another." is one of the requirements. How do we capture/track this? Is this part of the user story or is it something that's to be considered separately?

A: 

The first part belongs to a "business requirements" document (usually written by a business analyst). The first generations of this document are quite high level, but the final versions (several iterations later) are pretty detailed.

http://www.tdan.com/view-articles/6089

The second part (about tabbing) is part of another document - "UX spec" (shows all screens and describes user interaction). This one is usually written by a different person/team (Product or UX team).

http://uxdesign.com/ux-defined-2

http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php

DmitryK
You're talking tradition full lifecycle methodology. User Stories are Agile-based and your approach doesn't apply.
Nissan Fan
My point was that the functionality is captures by a BA, while UX stuff is produced by the UX team (even in the agile world as part of the "conversation"):http://eagleeyevue.blogspot.com/Quote: The Conversation is where the dirty details come out. People wonder about the role of business analysts or user experience people in agile. Their role is to be prepared to have a effective and productive conversation. This is where agile’s lightweight documentation approach wins because the verbal tradition forces clarity
DmitryK
A: 

User stories should be short statements in 1 to 3 sentences.

http://en.wikipedia.org/wiki/User%5Fstory

I want to be able to tab from one textbox to another is another user story.

You can track these things in a tool like www.rallydev.com, or just any type of task tracking tool (SharePoint, Excel even ... etc.).

Next thing you do is prioritize.

Nissan Fan
From what I understand, a user story isn't supposed to be "techincal", so in this case, whether the user can tab from one to the next field or use a mouse, is an implementation detail. That's why I said it was a detail, and not a user story. Of course that's just my understanding of it.
Jiho Han
Also I'm sure there are tons of other little tasks that need to be done in order to satisfy that user story, such as UI and other non-functional requirements like performance, audit, etc.
Jiho Han
+2  A: 

A user story captures the essence of a feature, not the details, a story is a support for the discussion.

So, to answer your question, details are transmitted orally during a discussion, because face to face discussion is the most effective communication media. If you feel the need, details can be captured as notes on the back of the card (if you are using cards) or... in a "notes" field if you are using an electronic tool. Actually, I usually use a "how to demo" field too to capture a high-level description of how this story will be demonstrated at the sprint demo and use very brief "notes" for any other info, clarifications, references to other sources of info, etc (credits to Henrik Kniberg's famous Index card generator). If find this very handy, especially when using executable specifications.

PS: your story is perfectly valid and its a good practice to include the benefits in your template ("As a role, I want action so that benefits").

Pascal Thivent
The reason I am concerned about tracking is that these details will need to be verified in order for a user story to be done, right?So if everything is just sitting on someone's (or the collective) head, then there's a big chance something will be missed.
Jiho Han
This is a good reason. I've updated my answer accordingly.
Pascal Thivent
A: 

Yes, that is problem we also have a lot. On the one hand, user stories need to be conscise, on the other hand all the nitty gritty details must be put somewhere.

We use XPlanner, and we solve this by putting the short description into the text body of the user story. Then we use XPlanners "notes" feature (arbitrary text or files that can be attached to a user story) for the details.

That way we can add as much information as necessary to a user story, without cluttering up the user story text itself. You can also refer to external documentation, if you don't want to have everything in XPlanner.

This approach works quite well for us.

sleske
A: 

Just taking a rough stab...

As a sales rep,
I want all data entry and navigation to be accomplished using the keyboard
so that I don't have to take my hands off the keyboard
(and so that we comply with accessibility guidelines).

Or

As a business,
We want all our products to be fully usable using only keyboard input
So that we can sell to customers who require accessible software.

MsLis