通常人们会将User Story和Use Case放在一起比较，虽然二者在形式上具有一定相似性，但是究其本质来说，还是天渊之别的。这一点，专业BA李默同学总结的格外准确：“用户故事是可见的商业价值，而不是功能描述”。想要更好的理解这句话，需要了解什么是好的用户故事。好的用户故事，可用INVEST原则来概括：

I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable

我个人觉得，这个总结虽好，但不免分散注意。要我说，想把握好User Story，只用把握两个就够了Negotiable和Valuable。那么首先要确定什么是Negotiable的。User Story有一个流传广泛的书写形式：

As <role>, I'd like to <action>, so that <benifit/value/goal>.

为了更好的获取story还有很多最佳实践，比如personas, 比如business process modeling，其实这些全是糖衣炮弹，As, I'd like to都是噱头，就是为了把用户忽悠晕了，然后图穷匕现直取商业价值和目标。一旦商业价值确定下来，role, action都是可以negotiable。比如李默之前在文章里举的用户登录的例子，输不输用户明密码？可以商量嘛！是不是只有注册用户可以享受个性服务？可以商量嘛！关键是用户想要什么，至于怎么实现这些到头来都是可以商量的，都是Negotiable。只有客户的商业价值是不能商量的，也没的商量。价值没有了，目标不存在了，这个User Story也就没用了，商量啥？重写一张就好了。

因此user story又有另外一个名称，叫requirement placeholder。就是客户价值的"立此存照"。至于具体需求，那么就到iteration plan meeting上是商量吧，看看当时什么样的形式（功能）才是最符合用户需要。到此，其实大家可以看出来了，user story重点就不再How上，而是在Why上的。有了why，且可Negotiable，把握了精神，你就是按用例来写需求又有何妨涅？

有了valuable和negotiable的想法垫底，在看看基于user story的初步计划制定——也就是有名的prioritization——就容易理解多了。用户根据每张卡的价值，自行比较作出决定，大体场景就跟向神仙许愿一样。

神仙：我可以满足你一个愿望。
我：我要荣华富贵！！！
神仙：哦，荣华富贵，那么要不要爱情涅？
我：恩，这个...那我要忠贞的爱情好了！！
神仙：哦，忠贞的爱情，那么要不要健康平安呢？
我：呃....
repeat 无数次，最终我要了一件过冬的皮猴...