因此，为了回答您的问题，详细信息将在讨论期间口头传达，因为面对面的讨论是最有效的沟通媒体。如果您觉得有必要，可以将详细信息作为注释记录在卡片背面（如果您使用卡片），或者……如果您使用电子工具，则将其记录在“注释”字段中。实际上，我通常也使用“如何演示”字段来捕获如何在冲刺演示中演示这个故事的高级描述，并使用非常简短的“注释”来描述任何其他信息，澄清、对其他信息来源的引用等（归功于 Henrik Kniberg 著名的 索引卡生成器）。如果发现这非常方便，特别是在使用可执行规范时。
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").
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.
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.
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).
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.
Agree with others, that this is viable story, but capture the (derived) requirements may be better captured elsewhere.
Software Developers and Business types are familiar with different terminology some what may simple to understand by one (data structures) may mean nothing to another. The User Stories is a tool or a means by which business user can convey a message as a starting point which is expanded on (with tests, details, etc).
Oral Communication can be effective, but the effectiveness is dependent on the receivers ability to hear and comprehend the meaning of the message. This is where oral communication can fail. Different types of communication offerring more or less formal forms of communication. Vocal communication is an "informal form of communication" which risks the message being misheard, misinterpretted, and misunderstanding. Just like the game played as a child, where one child whispers a message to another child, who tells another, until all have heard it...When the last child tells the message to the group it usually has been misinterpreted then misinterpretted again, causing a degraded message.
发布评论
评论（6）
用户故事抓住了功能的本质，而不是细节，故事是讨论的支持。
因此，为了回答您的问题，详细信息将在讨论期间口头传达，因为面对面的讨论是最有效的沟通媒体。如果您觉得有必要，可以将详细信息作为注释记录在卡片背面（如果您使用卡片），或者……如果您使用电子工具，则将其记录在“注释”字段中。实际上，我通常也使用“如何演示”字段来捕获如何在冲刺演示中演示这个故事的高级描述，并使用非常简短的“注释”来描述任何其他信息，澄清、对其他信息来源的引用等（归功于 Henrik Kniberg 著名的 索引卡生成器）。如果发现这非常方便，特别是在使用可执行规范时。
PS：您的故事完全有效，并且在模板中包含好处是一个很好的做法（“作为一个角色，我想要采取行动，以便好处 em>”）。
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").
用户故事应该是 1 到 3 句话的简短陈述。
http://en.wikipedia.org/wiki/User_story
我希望能够使用 Tab 键从一个文本框到另一个文本框是另一个用户故事。
您可以在 www.rallydev.com 等工具或任何类型的任务跟踪工具（SharePoint、Excel 甚至...等）中跟踪这些内容。
接下来你要做的就是优先考虑。
User stories should be short statements in 1 to 3 sentences.
http://en.wikipedia.org/wiki/User_story
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.
只是粗暴地刺了一下...
或者
Just taking a rough stab...
Or
第一部分属于“业务需求”文档（通常由业务分析师编写）。该文档的第一代水平相当高，但最终版本（后来的几次迭代）非常详细。
http://www.tdan.com/view-articles/6089
第二部分（关于选项卡）是另一个文档的一部分 - “UX 规范”（显示所有屏幕并描述用户交互）。这通常是由不同的人/团队（产品或用户体验团队）编写的。
http://uxdesign.com/ux-define-2
http://www.uxmatters.com/mt/archives/2007/05 /sharing-ownership-of-ux.php
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
是的，这就是我们也有很多的问题。一方面，用户故事需要简洁，另一方面，所有的细节都必须放在某处。
我们使用 XPlanner，通过将简短描述放入用户故事的文本正文中来解决这个问题。然后我们使用 XPlanners“注释”功能（可以附加到用户故事的任意文本或文件）来获取详细信息。
这样我们就可以向用户故事添加尽可能多的信息，而不会弄乱用户故事文本本身。如果您不想将所有内容都包含在 XPlanner 中，您还可以参考外部文档。
这种方法对我们来说非常有效。
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.
同意其他人的观点，这是可行的故事，但捕获（派生的）需求可能在其他地方更好地捕获。
软件开发人员和业务类型熟悉不同的术语，有些术语对一个人来说很容易理解（数据结构），但对另一个人来说却毫无意义。用户故事是一种工具或手段，业务用户可以通过它来传达消息作为扩展的起点（通过测试、细节等）。
口头交流可能是有效的，但其有效性取决于接收者听到和理解信息含义的能力。这就是口头交流可能失败的地方。 不同类型的通信提供或多或少正式的通信形式。声音交流是一种“非正式的交流形式”，存在信息被听错、曲解和误解的风险。就像小时候玩的游戏一样，一个孩子向另一个孩子低声传达一条信息，另一个孩子又告诉另一个孩子，直到所有人都听到为止……当最后一个孩子向小组讲述该信息时，它通常会被误解，然后再次被误解，导致消息降级。
Agree with others, that this is viable story, but capture the (derived) requirements may be better captured elsewhere.
Software Developers and Business types are familiar with different terminology some what may simple to understand by one (data structures) may mean nothing to another. The User Stories is a tool or a means by which business user can convey a message as a starting point which is expanded on (with tests, details, etc).
Oral Communication can be effective, but the effectiveness is dependent on the receivers ability to hear and comprehend the meaning of the message. This is where oral communication can fail. Different types of communication offerring more or less formal forms of communication. Vocal communication is an "informal form of communication" which risks the message being misheard, misinterpretted, and misunderstanding. Just like the game played as a child, where one child whispers a message to another child, who tells another, until all have heard it...When the last child tells the message to the group it usually has been misinterpreted then misinterpretted again, causing a degraded message.