在产品Backlog以及Sprint任务板上经常看到技术类的故事。通常情况下PO不能解释清楚这类故事，更不用提这类故事的价值了。这其实对PO同学很不礼貌。
故事一 – “XX作业优化”
上个月在某团队看Sprint任务板的时候，发现一个技术类的用户故事“XX作业优化”。故事比较大，是技术同学提的，PO同学听不懂，技术同学的解释是，由于原系统的设计问题，数据库表格之间的联结不能够支持大数据量的需求，因此必须实现这个技术类的用户故事，为“将来”打好基础。
提出这个用户故事有几个假设？
- 针对问题的假设 – 我们现在的表格设计马上就不能应付当前业务的发展？
- 针对方案的假设 – 我们的数据库表格效率是大业务量系统性能的瓶颈，因此数据库的的修改一定能够帮到我们？
这两个假设都是基于业务的假设，而PO同学其实是最接近客户，最了解业务的。所以我们技术团队应该从业务上给PO同学证明这个用户故事的价值。而不是不经过论证，马上就着手实现。所以我们的技术团队应该提出如下的用户故事：
- 故事1：论证当前系统的理论负载上限，可能的做法是往数据库里面持续插入数据，然后作压力测试，看什么时候可以把系统压爆。这样的故事通常只要很短的时间就能完成。
然后理论负载上限值告诉PO同学，PO就可以根据这个系统理论上限值以及现在业务的发展情况决定什么时候是合适的时机着手调整表格
- 故事2：论证数据库表格联结是系统的性能瓶颈。如果数据库表格联结不是瓶颈的话，我们再优化也是不起作用的。可能的做法是对系统作Profiling，找到瓶颈在哪里，我们的理论负载值应该是由性能瓶颈决定的
如果瓶颈是数据库表格设计，然后根据理论上限值和业务发展情况，决定是否需要重构表格设计。
故事二 – “XX计算性能优化”
再看另外一个故事 – “XX计算性能优化”。通过看这个故事能够帮助谁？解决他的什么问题？来看这个故事的价值。其实多问几个Why，很快就发现，这个故事其实是为财务同学做的，现在月底的作业运行时间比较长，财务不能在两天内完成结算，而且现有方案容易出现超时，从而导致数据同步的问题。因此保证我们的财务能够无差错地完成作业、缩短结算时间才是我们真正要解决的问题，这些都是业务故事，而不是技术故事。
