蒙恩摘录的答案是我回答另一个问题的。

‍‍我尝试回答下你的这个问题：

你问了“story的可协商是怎么体现出来的?”

所以你就是想写出具有可协商性的story咯。

可协商性的体现是说写story的时候，

不要细化到特别具体的解决方案，

而是将可能出现的解决方案进行一丢丢的抽象。

注意：这里只谈怎么写出具有可协商性story。

你可能会看到有些story写的特别细致，但最后名不副实，实际用的是其他的解决方案来满足需求实现价值的。

那其实这样的story，是不具备可协商性的。因为已经对不上了。。。

首先story验证的可协商性。

用户可协商性对我们来说就是， 为达目的，在原来方案走不通或者有了更优的方案时，在知会客户并且获得认可后(特别是流程或者页面有变动时)，尝试使用不同方案替代传统方案来完成相关需求（以上引用上海分院学员  赵跃   不含本人观点）

可测试性就是为确保达到需求，用户story完成后需要进行测试，举个例子，我想要在我1千岁的时候，跑完一趟马拉松，便于我成为年龄最大的运动员。不可能等到他到1千岁的时候测试~就是这么一个道理。。story中要现实。。能够进行测试，也要清晰，我想要一款最好用的APP，提高我生活品质，  最好用的APP？哪个是最好用的APP？  APP是什么类型的都没有~

最后的验收标准

验收标准作用详细的给开发人员对每个功能点详细的进行描述，在项目验收的时候对照项目验收标准进行验证

一个正常的story对应的功能点，比如说账号密码登陆的story有了，项目验收标准详细的列举每一个功能点，账号密码是什么格式，账号几位数。密码几位数，都要详细的写出、