有一次我问一家开发“敏捷工具”的著名公司的开发团队：“你们的Product Backlog里面有多少用户故事？”他们的回答让我大吃一惊。“10万个”。怪不得这家公司要雇佣那么多优秀的人才，怪不得他们需要一个“敏捷工具”来管理他们的需求列表。。。
症状
- 产品待办事项列表有过多的条目要完成
- 产品待办事项列表中有很多低优先级的小故事
- 除了因为地域的原因，还需要电子工具来维护产品待办事项列表
- 需要缺陷追踪系统来追踪所有的Bug
诊断
市场是不断变化的，客户的想法也是不断变化的，而冗长的产品待办事项列表会产生种种副作用：
- 维护成本高，其中也包括电子工具的成本
- 过多的条目会影响到新条目排期
- 排优先级十分困难
症因
- 梦想可以一下子把产品想法都列出来，不愿意通过不断迭代，持续反馈来打磨产品
- 完美主义，没有认识到不完美的产品可以诱发客户的反馈
- 不敢或者不会砍需求
处方
- 把低优先级的小故事删掉
- 把低优先级的小故事合并成大故事
- 仅仅在产品待办事项列表中维持够两个Sprint的工作
- 引入周期性的产品待办事项梳理活动
