编写需求的若干要素

独立性
每个User Story尽可能独立。这样可以减少需求之间的依赖关系。这样开发和测试的时候，自由度都会比较大。有依赖关系的User Story在估计工作量，做计划，评估优先级的时候都会比较困难。当然，某些情况下，依赖关系也不可避免。

可讨论性
User Story仅仅是简单描述用户所需要解决的问题，并非详细的解决方案。通常来说，用户的实际问题变化较少，变化较多的是解决方案。软件开发过程中常见的需求变化，其实多半指解决方案变化。如果User Story限制太多而缺乏可以讨论的空间，那么会限制在获得用户反馈之后，修改解决方案的空间。又或者会造成User Story本身不得不经常修改的问题。

用户价值
User Story必须是有价值的。如果User Story是描述了用户实际问题，那么用户肯定愿意为解决这个问题而买单。如果User Story没有用户价值，那根据这个需求开发的功能很有可能是华而不实的产物。当然，有些User Story未必在短期内，或者直接提供价值。

可估计性
如果开发人员无法对需求做出工作量估计，那么就无法安排开发计划。所以无法评估的需求是需要改进的需求。在实践中，这类问题通常由于User Story过大，或者开发人员缺乏相关领域知识所导致。如果这些问题得不到解决，即使把需求强行塞给开发人员，最后也会导致需求无法实现等等后果。

足够小
User Story越小就越简单，越容易理解，越容易评估，越可控。

可测试性
每个User Story都必须是可以被测试的。换句话说，每个需求在编写的时候，都必须有通过条件。在实践中，这些通过条件恰恰是开发和测试人员最容易理解和执行的标准。如果需求无法被测试，那说明团队并没有真正理解这个需求。