在当下，处于 VUCA 时代的咱们也在面临着来自客户的易变、不确定、复杂化、模糊化的需要。这种多变的需要推动着咱们要增强与客户的沟通交流，通过用户故事来廓清客户需要，帮忙客户打造对他们来说有价值的产品。所以咱们该怎么廓清用户故事呢？
一、谁来编写用户故事？
用户故事是由谁来写呢？个别状况下，肯定是最靠近用户的角色来负责编写用户故事，这个角色个别状况下是客户或者产品负责人。通常客户写进去的需要也不能称为严格意义上的用户故事，这就须要产品负责人在与客户确认的根底上再加工，造成一个残缺的用户故事。
如果在某个团队中，用户故事是由测试人员或开发人员编写的，那咱们也同样须要明确这个用户故事是通过客户和产品负责人确认过的。同样，用户故事优先级的排序也是须要最贴近用户侧的人员来进行确定，如果研发团队自行决定用户故事的优先级，那么就有可能呈现最先实现的用户故事有可能不是最重要的，而是最好实现的。
那如何编写用户故事呢？能够通过对用户的访谈、市场考察等形式来挖掘用户需要，而后依照 INVEST 准则来正当编写用户故事。
在这个阶段，咱们要留神的一个事件是，为了达成麻利团队的自组织，进步团队成员的积极性与参与感，咱们能够不明确到底是谁来编写用户故事，而是让每一位团队成员都参加编写用户故事。这样的话可能激发团队成员的责任意识，缩小成员之间的互相推诿。
二、什么时候应用用户故事？
用户故事明确了什么角色想要什么性能，以便于实现什么价值或目标。所以在每实现一个性能之前，咱们 要明确为什么要做这个性能以及怎样才能达成这个目标或价值。
但咱们须要留神的是，不是所有的工作都须要用用户故事来表白，比方团队的一些事务性的性能就能够以工作的模式而非用户故事的模式来表白，因为这类事项不能产生对客户无益的价值。对于可能间接对客户产生价值的需要，咱们能够用用户故事来表白。
因而，咱们要真正弄清楚真正面对用户的用户需要（用户反馈的 Bug、撰写用户手册的需要、产品功能性需要等），咱们通过用户故事来表白；而一些团队外部的改良问题（如进行结对编程、外部发现的代码标准、某一部分的代码重构等），咱们能够用团队达成共识的表述形式来出现。
三、用户是谁？
在做项目管理的时候，咱们肯定要与用户接触、沟通，理解用户的实在需要和理论的应用场景。在个别状况下，很多公司只有销售人员在接触客户，研发侧人员以及产品负责人等离客户十分远，那在这种状况下，团队很容易呈现“闭门造车”的景象，最终交付的货色无奈投入到理论应用环境中，也不是用户真正须要的。
所以整个技术团队须要搞清楚用户是谁、用户在哪以及用户有什么需要这几个问题。而在这个时候，咱们能够用用户画像、影响地图、用户故事地图、同理心地图、客户旅程地图等实际（这些实际能够在融·软件项目管理举荐库中进行理解）找出真正的用户，进行精准的需要获取。而针对一些中间件、微服务等，咱们能够通过将这些中间件及微服务的上下游零碎定义为零碎用户，也可能比拟轻松地编写出这些零碎用户的用户故事。
四、用户故事标准
用户故事的标准其实也是一个常见问题，咱们能够通过一个小视频来具体理解如何来编写用户故事：如何写好用户故事？
五、勿以唯故事点论
尽管咱们在估算用户故事的时候会应用故事点估算，但适度地关注故事点也会让咱们事与愿违。首先咱们要明确的是 故事点估算没有一个对立的规范，每个团队都能够依据本身的理论状况确定本人的基准故事点。
这里有几个关键环节咱们要留神：在理论实现某一迭代的时候，咱们要关注这个迭代交付了多少性能，而不是实现了多少故事点；不要做团队与团队之间的故事点横向比照，因为两组并不是齐全一样的条件，所以没法进行直观地比照；咱们只用故事点来执行迭代打算，不应该将故事点与绩效治理挂钩。
六、定义“就绪”“实现”与“验收规范”
在用户故事被放入迭代打算之前，咱们要确认用户故事的“就绪”状态。团队之间要就“就绪定义”达成共识，比方独特制订出一个查看列表，通过此查看列表的用户故事即为“就绪”，能够排进迭代打算中。同时，能够依据用户故事的类型来制订不同类型的用户故事“就绪定义”。此外，还有一个关键点在于，“就绪定义”须要定期检查更新。
既然明确了用户故事的“就绪”，那么咱们也要明确用户故事的实现规范。如果咱们对用户故事实现没有一个对立的规范，那么就会呈现研发人员感觉写完代码就算实现了，而测试人员认为编码后自测、而后通过功能测试之后才算实现的状况，这种状况会大大增加沟通老本，升高工作效率。
所以 团队须要给用户故事一个实现的定义，比方通过自测、功能测试、集成测试能力算用户故事的“实现”，也就是咱们所说的“DoD”。
那用户故事实现了，它能达到用户的称心吗？这里就牵扯出了一个细节问题，团队制订的用户故事的“实现定义”只是确认了这个用户故事或这个性能做完了，然而并不能明确这个性能能够满足用户的需要。那为了解决满足用户需要这一问题，咱们能够设置用户故事的验收规范。
验收规范的设置须要用户、产品负责人及团队一起来探讨实现，它可能满足最后的用户故事的内容。也就是说，如果咱们要做一个网站注册性能，最终做进去了一个通过邮箱号实现注册的性能，这个性能是通过自测、功能测试后明确实现了的性能，然而用户心愿可能通过手机号间接注册，这个实现了的性能并未满足用户的需要。那这样的话咱们做进去的性能并不是用户所冀望的，所以咱们要通过验收规范来满足用户的冀望。
咱们能够通过“Given/When/Then 格局”来编写验收规范，举个例子：用户故事是“作为一个没有在这个网站上注册的用户，我心愿可能开发一个网站注册性能，以便于我能在网站上发表本人的舆论。”那么该用户故事的验收规范则是：
场景：网站用户注册登录；
- Given：鉴于我的角色是网站未注册用户；
- When：当我点击网站右上角的“注册”按钮；
- Then：零碎就会弹出注册页面；
- When：当我输出手机号，点击发送验证码，并填写收到的验证码，点击“注册”；
- Then：零碎显示登录胜利。
在做用户故事实际的时候，咱们常常会遇到一些问题，那本文其实给用户故事提供了一些“解题思路”，也心愿大家在我的项目过程中可能正确、无效地应用用户故事实际，来推动我的项目胜利。