1. 在用户故事中，将开发中的相关人员作为系统用户角色
比如 as a po/apo/ppo/developer/tester/manager/integration engineer， I want 。。。
必须注意，As a 中的role是运行时实际使用该系统的用户角色，不是开发时干系人的角色
包括客户文档相关的用户故事，也要以实际使用该文档完成某项任务的视角来描述：什么角色，什么情况下使用该文档用来做什么，达到什么样的可衡量的目标等，而不是某经理要求该文档。
2. 把系统的发布版本放入用户故事标题中
如果把系统的发布版本放入用户故事标题和描述中，这样当优先级变化，需要把这个故事移动到下一个发布时标题就需要改动了，带来不必要的额外工作。
一种特殊情况：如果是需要发布给客户的系统补丁包、增强包等软件构建包的代号，这些交付的软件构建包属于一个大的发布版本中的多次规划中的交付，而且该用户故事必须包含进去，该包才能对外交付，此时该软件构建包代号还是可以写进故事标题中的。
3. 没有明确详细定义的验收条款（Acceptance Criteria）
用户故事中的重要的3C中的Confirmation缺失，会造成团队不清楚做到什么程度才能算Done. 好的做法是用“Given，When，Then”的格式写明详细的验收场景，详细到团队能够完整准确理解需求的程度。
验收条款有些地方也称之为为Conditions of Satisfaction，是同一个意思。
4. 用户故事描述或验收条款中使用模糊词语
比如在要求高可用性的用户故事中，只描述想要高可用性，没有描述具体的场景下发生什么事件后系统的行为应当如何才能成为为高可用性，会造成团队对如何实现和测试不能很快明了。
5. 用户故事没有设定明确的完成定义（DoD）
DoD通常是Acceptance Criteria再加上一些流程上的质量控制、系统的设计属性、维护沟通需要的文档等要求而构成。
每一个用户故事都应该有其DoD， 可以使用统一的DoD模版。针对特定的用户故事，在模版基础上注明不适用的项，以及必要时的额外要求形成专门针对该故事的DoD。
6. 没有估算故事大小，或给定太随意，或过大无法放入一个迭代内，或过小管理不便
用户故事的估算故事点是用来指导迭代计划的制定的。如果不使用故事点，那就要做到每个故事粒度大致相同，这样通过故事的个数也可以做迭代计划，否则就应该正式使用故事点，只不过要注意不要过度追求估算的准确度，以及不要将完成的故事点过度用于其他目的。
为了清晰地知道哪些故事需要拆分，可以为要开始的迭代的故事设置一个最大故事点值，比如8，当一个故事的故事点超过8时预示着要拆分。
值得一提的是，当故事太多时，可以使用两级故事管理需求，第一级特性（史诗故事)，第二级故事，一个发布版本中通常包含10-20个特性，每个特性可以平均包含10-20个用户故事，这样即能做到宏观把控，也能做到快速反馈和适应变化。
7. 明知一个迭代内该故事完不成，还不拆分，或做计划时让该故事跨越多个迭代
用户故事的粒度要小到放到一个迭代之内，并且通常一个用户故事只占用团队能力的1/4-1/6，跨越多个迭代的用户故事违背了迭代计划的基本原则，无论是什么原因造成的，都应该拆分它。
8. 不按可交付和达到快速反馈的目标而拆分
用户故事的拆分以交付和快速反馈为导向，首要是针对外部客户，其次可针对内部客户，再次为团队自身提供反馈搞清楚需求和约束，不要纯粹为了“节省”时间而拆分。
9. 盲目追求不现实的完整端到端验证
当团队是以组件方式构建
