，用户故事的实现也是组件式实现的背景下，盲目要求所有组件的用户故事必须端到端测试通过才能done，造成循环依赖，互相等待，再加上可能没人负责对整个feature涉及的所有团队做计划上的协调，实际上迭代计划各自为阵，每个团队都把用户故事的完成日期设置到最后截止日的迭代，不仅原定目标未达到，反而演变成waterfall模式。
比较好的做法：如果可能就组建feature team；做不到，则virtual feature team 或设置明确的Feature Owner角色负责协调所有涉及团队，或APO/PPO／PO定期的Sync会议；还做不到，使用内部交付模式，底层向上层交付，中层使用底层的真实系统以及上层的模拟系统验证；如果以上都做不到，则可以mocking自己团队外的组件，mocking时写明具体验证方式和条款，再留一个用户故事条目与真实组件集成，这样至少可以用来将真实进度和相互阻塞的问题分离并重点暴露出来，便于下一步的改进。
10. 没有按照团队能力排定未来几个迭代的迭代计划
由于没有持续排定未来几个迭代的计划，也就丢失了计划的可见性和预见性，不利于快速调整应对变化和聚焦在最有价值的东西上。
应该将团队的历史完成故事点利用起来，结合团队能力，排定在当下看起来相对合理的迭代计划，随着情况的变化，不断调整迭代计划。
用户故事基础知识
什么是用户故事
用户故事是从系统用户角度描述用户能做什么、需要做什么，从而完成一定功能的需求描述方法，描述使用的是日常或商业语言，便于用户理解。它捕获需求中的“谁”、“什么”和“为什么”，往往可以精简到写在一张小纸片上。
大的用户故事，可以称之为史诗故事（Epic Story），通常特性（Feature）对应于史诗故事。
共同具有某种相关属性的用户故事又可以归为同一个主题（Theme），相当于商业类别或投资类别之类。
用户故事的3C’s （Card，Conversation， Confirmation）
Card卡片: 用户故事通常写在便笺卡上，这些卡片可以附带额外的细节信息用于明确需求。
Conversation对话: 用户故事背后的细节信息通过与产品负责人的对话而得到，通过不断地沟通使需求越来越清晰.
Confirmation确认: 验收测试条款用来确认该用户故事是否完成并且是否以期待的方式正常工作.
用户故事书写的几种格式
As a , I want so that
As a , I want
In order to as a , I want
As , I because .
一般使用第一种，在Benefit比较明确的情况下，使用第二种
用户故事条目的关键属性
编号
标题
描述
状态
优先级
大小
团队
迭代
完成条款
好的用户故事符合INVEST规则
Independent独立的：用户故事应该是自包含的，没有对于其他用户故事的内在依赖。
Negotiable可协商的：用户故事在进入当前迭代之前，都可以进行变更和重写。
Valuable有价值的：用户故事必须向最终用户交付价值。
Estimable可估算的：用户故事的大小必须总是可以估算的。
Small尺寸小：用户故事不应该过大，以至于无法在一定的确定性下进行计划、分派和排列优先级。
Testable可测试的：用户故事及其相关的描述必须提供必要信息，使得可以对其进行验证是否完成。
