大胆开麦：用户故事真的很难用

作为一个角色，

我希望有某个功能，

以便实现某种业务价值。

通过这个格式，可以明确这个功能是为谁设计的，带来什么价值。而不仅仅是提到一个功能，因此可以产生对话和确认（3C原则）。

但是，用户故事的应用过程中，并不是像描述的这么好，下面是一些常见的用户故事的反模式：

1.用户角色和功能不一致

作为一个VIP用户

我希望有个晒单有礼的功能

以便获得福利

问题：凭什么VIP想要这个福利，平台就要提供这个功能？

2.用户角色和目标不一致

作为一个VIP用户

我希望有个晒单有礼的功能

以便帮助商家推广商品

问题：哪个VIP会有这种想法？

3.用户角色和实际用户角色错位

作为一个商家

我希望提供给VIP一个晒单有礼的功能

以便帮助商家推广商品

问题：实际用户是VIP，并不是商家

4.错误的用户描述

作为一个开发人员

我希望完成VIP晒单有礼功能

以便满足迭代计划

问题：对用户故事的结构理解错误

5.技术故事难以硬凑到这个格式

作为一个开发人员

我希望提供一个查询接口

以便其他系统能够从本系统查询数据

问题：技术故事往往没有用户

6.简单功能硬套格式，无法描述出合适的价值

作为一个VIP

我希望有一个登录系统功能

以便使用系统

问题：直接写“登录”，能否表达同样的意思

7.两个角色可以使用同一个功能

作为一个请假者的上司

我希望能够通过审批功能，批准请假

以满足公司规定的要求

作为一个请假者的上司的上司

我希望能够通过审批功能，批准请假

以满足公司规定的要求

作为一个HR

我希望能够通过审批功能，批准请假

以满足公司规定的要求

是不是觉得用户故事就是一个八股文式的格式，实际上并没有起到帮助作用。那么为什么会产生这种问题？是因为照本宣科的Scrum导入过程，外部敏捷教练告诉团队，必须使用用户故事，这些问题他们也没见过，也不会解决。

并且在Scrum中管理的是backlog，而不是用户故事。请参考Scrum Guide，自始至终就没有提到过用户故事。而用户故事只是作为backlog的其中一种表现形式，但这个格式还具有如此多的问题。