需求是一种沟通工具，可用于引导大家对特性达成共识。 Scrum中，需求细节是在开发期间持续不断的对话中商讨出来的，而且是等到团队开始构建功能的时候，及时、刚好地细化这些需求为团队提供支持。
并非所有需求都必须在相同时间做到同样详细。即将要做的需求比一段时间内不准备开发地需求更小更细。我们采取逐步细化地策略，及时把庞大、较少细节地需求分解成一组更小、更细地条目。
在使用Scrum进行开发时，我们会为需求创建PBI占位符。这些条目通常以故事地形式呈现，在Scrum过程中流动，明显侧重于以对话方式来澄清需求地细节。
用户故事是可用于陈述业务价值地一种简便格式，适合各种PBI，特别是特性。用户故事地制作方式旨在帮助业务人员于技术人员双方都能理解需求。用户故事地结构很简单，为会话提供了一个理想地占位符。
开发团队、产品负责人和利益干系人会在对话中发现并探讨需求中地细节。用户故事仅仅是对进行此会话地承诺。
用户故事还要包括确认信息，它体现为满意条件地形式，是接收标准。
用户故事是一种优秀地工具，可以承载者客户或用户价值地条目贯穿于Scrum地价值创造流程。
用户故事应该是独立的，至少以应该是相互间松散耦合地。相互依赖程度高的故事会使估算、拍优先顺序和规划复杂化。
用户故事应该是可协商的。故事不是以前期需求文档形式写就的书面合同，相反，故事是占位符，用于协商细节。好故事能够清晰的捕捉那些业务功能是用户想要的。它们要为产品负责人、利益干系人与团队留出谈判控件。
列表中所有的故事都必须有产品负责人以客户与用户代言人的身份认可他们的价值。
用户故事应该是可估算的。估算指明故事的大小，因此也指明故事的工作量和成本。
