经常会有人让我帮忙，“Daniel，能不能教教我如何把我现有的需求文档转换成用户故事？”。问出这样的问题，说明他根本不理解用户故事是怎样玩的。哪怕是把他的文档都翻译成了用户故事的样子，也不是用户故事。

症状

• 产品负责人负责写故事
• 产品负责人单独维护产品待办事项列表
• 团队等待产品负责人写故事
• BA负责把需求说明书翻译成用户故事

诊断
事实证明对于产品开发活动来说，递增跟迭代工作方式更加有效。因为产品开发活动的本质是一种探索，有很多不确定性，比如市场、技术、业务、人员变化等等。很难一开始把一切都想清楚。Liz Keogh说过，“一个常见的错误是大家认为只要分析的足够多，就能够做对”。

产品研发是一个协作式创造的活动。团队内各种角色人员的对于待解决问题以及解决方案的共识对于协作式创造十分关键。接力棒式的协作方式会导致知识的丧失与不准确。尽管使用了用户故事以及产品待办事项列表，其实还是受到传统开发方式思维的影响。这种思维方式的会导致如下问题：

• 忽视真正要解决的问题。开发团队距离真正客户太远，信息传递到开发团队后已经变得不准确，开发团队很难了解真正要解决的问题
• 复杂的解决方案。为了应付“可能”有的变化，开发团队往往开发出十分复杂的技术和业务方案，从而提高维护成本
• 更晚发现的缺陷。业务、开发以及测试对于同一个需求的不同理解必须等到产品开始实现或者完成后才会暴露，不同的认识会导致更多的产品缺陷。
• 更高的Bug Fixing成本，因为Bug已经隐藏很久，在那之上有累加了很多的代码。
• 大大降低应付变化的能力

症因

• 传统开发方式思维的影响，角色之间职责的清晰划分
• 开发团队参与需求的讨论和梳理的意愿不强
• PO不愿意放手让团队一起讨论并梳理需求

处方

• PO与团队一起梳理产品待办事项列表，包括：写故事、建立Story Map、切分、估算
• 让测试人员提前调研用户故事的验收条件，并与PO和开发一起评估
• 周期性的产品待办事项列表梳理
• 项目启动时，只用准备第一个Srint的产品待办事项列表。