用户故事 不是合同。它们并不意味着功能的精确，详细的说明。它们不应固定在石头上。
我最近引用了 ‘Invest’ acronym 作为记住和评估什么才是好的用户故事的一种方式。
* N *在‘Invest’ stands for 面议.
用户故事是一个提醒。提醒您进行有关功能的对话。提醒您进行协作，以便及时了解要开发的功能的详细信息。可以在 用户故事卡 捕获并澄清细节。
用户故事应该有足够的信息来捕获功能的本质，而无需太多的基础知识协作。
但是，用户故事不应包含太多细节。过多的信息可能意味着用户故事是完整而准确的。
由于语言交流的丰富性和双向性，因此可以从对话中获取更多信息。关于用户故事的太多信息可能会导致人们无法合作，因为他们认为他们已经知道了他们需要的一切。然后你输了。你输了 将书面提醒与口头，面对面交流相结合的优势.
我的一个 敏捷开发的10个关键原则 就是它‘敏捷需求勉强够用‘。足够但是勉强。没有更多的信息比以合理的效率进行开发和测试所需的信息更多。
有时可能是一个要求‘specified’以一种特殊的方式，开发人员发现它’难以实施。或那里’一个更简单的选择。在这些情况下，较小的折衷或对该功能的方法稍作更改，就可以简化并加快实施。用户故事应该可以协商，因此，当用户或客户时，不会浪费时间’可以轻松实现目标。
因此，使用 ‘Invest’ acronym，我最近如何 用户故事的示例 面议？
也许吧’有点详细吗？它暗示了按钮背后功能的特殊设计方法。尽管这实际上只是有关应采用的设计方法的关键决定的说明；功能本身的设计没有详细信息。
视觉方法意味着特定的屏幕布局，尽管它’表示是线框而不是屏幕截图。就个人而言，只要人们认为这是可以商量的，我认为一张图片值得一千个字，这是非常值得的。
该示例可能与用户故事真正需要获得的详细信息一样详细。当然我会’希望看到每个如此详细的用户故事。许多用户故事可能没有那么详细地描述。并且仍然（勉强）足够。
凯莉
