第二章用户故事
1.用户故事应该是独立的。如果不是独立，要从2个角度进行考虑，1个是合并，这2个故事能否合在一起，2.能否从其他的角度进行拆分。
2.用户故事是可以讨论的，用户故事描述只是简短的话，故事的详细信息是通过对话、讨论补充的。
3.用户故事应该是有价值的，即使是技术故事 也应该从用户价值的角度出发。
4.用户故事应该可以估量的，不能估量的原因
1.缺乏领域知识 不理解故事，应该和写故事的人详细的讨论。开发不需要了解所有的细节，但需要对故事由一个大概的了解。
2.缺乏技术知识 增加一个探针实验故事，探针本身需要增加一个最大时间量。
3.故事太大
复杂故事 增加调研故事
复合故事 由多个小故事组成，考虑从其他的维度对用户故事进行拆解。
5.用户故事应该可以测试的
功能新的故事 应该都是能测试的，应该考虑增加自动化测试。
非功能的故事，应该量化指标
个人感受
很多故事都没有很好的拆解，如果开发任务不能从源头的进行控制，那么会增加很多无用的功能。这本身对项目和团队都是一种极大的伤害，最终你会发现你一直在处理一些无价值的任务，而没有办法把时间和精力集中到真正的业务价值。劣币逐良币的现象最大的问题是消磨了整个团队对应整个项目的信心。
行动：对于每一个故事，都要严格把控一下，首先要确保故事能够像scrm所定义的那样，是否是一个真实的故事，以及其背后的价值。同时，要理解任务的界限不是那么的清晰，需要从中进行平衡不要让自己陷入牛角尖。
