用户故事

一，用户故事编写注意以下六个特征INVEST

独立的（Independent）
可讨论的（Negotiable）
对用户或者客户有价值的（Valuable  to  Purchasers  or Users）
可估计的 (Estimatable)
小的(Small)
可测试的(Testable)

独立的

我们要尽量避免故事间相互依赖。
发现有用户故事发生依赖可以采用如下方法解决：
将相互依赖的用户故事合并成一个大的独立的故事
用一个不同的方式去分隔故事

可讨论的

故事是可以讨论的，它不是签署的合约或软件必须实现的需求，细节处可以和开发人员以及客户团队讨论。

对用户或客户有价值的

“每个用户故事必须对用户有价值”，这句话听起来很吸引人，可那是不对的。
比如“所有数据库连接要通过一个连接池”，这只是对开发人员有价值，并不是对用户有价值，用户只关心实现后的结果，比如“我可以修改个人信息”。

可估计的

一般有一下三个方面导致故事不可估计
开发人员缺少知识领域
开发人员缺少技术知识
故事太大可以根据开发人员以往开发过的功能进行大概估计，或者把故事再拆分小一点。

小的

合适的故事大小由团队，它的容量及所使用的技术决定。满足每个人一天的工作量就好。

可测试的

用户决不需要花很长时间等待窗口出现”，这就是不可测试的功能性故事。
我们做一些修改：
“在95%的情况下，新窗口会在2秒内打开”，这就可测试。甚至更好的是写一个自动化测试来验证它
举例：我现在放一下聚美的购物车的用户故事，聚美在购物车处做的不是很好，通过用户故事可以明显感觉到用户购买东西操作步骤太多，不能立即购买，必须进入购物车。