想一想：
你们公司产品经理写的用户故事是什么样的？
你们公司的敏捷迭代是功能迭代还是故事迭代？
你们公司的敏捷项目管理是真敏捷还是假敏捷？
无论是系统还是看板，里面的内容是用户故事还是功能需求？
从这篇简短的小文章你将会获得：
1、另一个维度去理解和使用用户故事；
2、敏捷管理为什么会失败；
3、真正的迭代是什么？
一、用户故事的三要素
1、常规敏捷教练或其他书籍教给你的三要素
用户故事通常的格式为：
中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。
英文：As a , I want to , so that .
一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
功能：需要完成什么样的功能。
价值：为什么需要这个功能，这个功能带来什么样的价值。
嗯....... 看着很简单呀，那不是随便写吗？
作为一个用户，我想买东西，以便东西能到家
作为一个员工，我想申请一支笔，以便我能开会写字
........... 这是用户故事吗？产品经理、开发工程师、测试工程师你们喜欢这样的故事吗？
2、实战后的资深项目经理/PMO告诉你的三要素
主语+谓语+宾语
用户故事本身就是转化了一种沟通的语言、工具来进行沟通，所以需要结合语文语法来进行用户故事的编写，用主语+谓语+宾语的方式来进行描述，下面我们来举例看看：
比如：
感觉别扭的故事：作为一个管理员，可以展示所有用户信息，以便于……
PS：这样看着有点别扭啊，展示用户信息？这不是一个动作呀！
感觉舒服的故事：作为一个管理员，可以查看所有用户信息，以便于……
PS：哦原来是这样，是想（Query）查看用户信息啊
再比如：
感觉别扭的故事：作为一个管理员，可以新建用户，以便于新建一个用户
说明：想一想现在的网站、APP等，注册用户百万、千万都有，管理员会很无聊的去查看所有的用户信息吗？势必是要做一个有意义的事情才会去查询，但是上面的感觉对，又感觉很啰嗦，而且不知道要干什么。
感觉舒服的故事：作为一个管理员，可以新建用户，以便于可以快速的将用户进行分组
这个用户故事看起来特别的舒服了，但是也有问题，那就是分组，难道只能新建的用户才能分组吗，历史的用户怎么办，为什么我不能批量分组？
这就涉及到另外一层，真正的迭代，真正的MVP【这里不多赘述，感兴趣的朋友可以一起来交流，或关注下一期敏捷成功的秘诀】
所以采用上面的方式，可以真正的包含了角色，角色的行为动作以及在某场景下要达到的目的价值【不多赘述，仅抛砖引玉，更多细节请和老师交流】
二、用户故事的INVEST六大原则
Independent：独立性
用户故事之间应该是独立的，要尽量避免故事间的强依赖。如果依赖性特别强的话，会影响研发对故事的评估，也不利于去沉淀故事的标准。同时衡量优先级的时候也无法确定故事的先后顺序。我们可以使用脑图工具来架构你的用户故事组合
Negotiable：可协商
用户故事是对一个故事最简短的描述，不需要太多的细节，要留有很大的空间让客户、研发等进行充分的商讨，不要设置围栏。如果有太多太多的细节，容易造成故事在市场上的适用性、技术实现的局限性等。在沟通过程中大家会逐步把细节完善落地。
Valuable：有价值
首先要对价值有一定的认知，用户故事不是一个任务，而是一个未来的故事，这个故事是可以进行沟通，这样很多人才会说出来自己想要的价值故事
Estimable：可评估
用户故事本身就是一种转化语言便于交流及评估等，如果团队评估和认识到故事的价值、优先级、规模、计划等，那故事本身就是有问题的。对于无法评估还可能存在：对于业务领域知识面的缺乏（此时可以多讲述一些背景）、故事颗粒度太大（试着按照标准进行拆分、切片）、技术能力的局限（可以请技术leader参与评估）等。所以一个故事需要可评估
Small：短小
不可字面上理解用户故事越小越好，不要去局限。而是要正确理解，比如从可交付价值的颗粒度、从规模复杂度、工作量等方面。比如作为一个店铺，我想在电商网站上卖东西。这个故事虽然很小。但从交付价值、工作量上看就不是一个短小的用户故事。
Testable：可测试
试想一下，一个用户故事如果无法测试，那么这个故事的角色、行为和结果是不是就没有定义清楚呢？所以故事要可测试，也就是说定义了故事验收的标准，定义了开发用户故事阶段完成。
三、浅聊一下什么是敏捷迭代
回想一下，大家看板（或其他放用户故事的工具）上面的用户故事卡片是不是很好看，花花绿绿一整个白板？故事卡片上面的用户故事到底是需求描述还是什么？为什么说好的敏捷迭代感觉变成了功能拆分、瘦身迭代。
其实类似于以上的问题，往往不一定是流程本身的问题，问题出现在用户故事的规划、拆解上。
举例：作为一个管理员，可以新建用户，以便于可以快速的将用户进行分组
这个用户故事咱们上面聊过，作为一个管理员，通过一个创建（Insert）的一个动作，将（Data）通过一个前端表单填写后（对了 其中有分组的字段哦），成功的完成了将新增用户分组的这么一个故事。
接着讲故事：如果我可以通过关键字查询然后批量分组呢？这又是一个用户故事。有事一个迭代，因为需求是随着用户、市场等不断变化的，所以，你对咱们这里说的敏捷迭代有没有感觉？
最后，其实就形成了敏捷用户故事地图！
好了，本期咱先说这么多，特别细致的用户故事需要结合很多细节去组合使用，最后敏捷才能落地，才能发挥效果，更多精彩咱们下期再见！
1、【干货】Scrum敏捷项目管理，看这一篇就足够了！
2、量化敏捷项目管理案例分享，CTO连连称赞！
3、为什么Scrum敏捷管理不受大厂追捧了
4、如何采用最适合团队的Ops文化？
5、敏捷：看板、目标如何驱动
6、云原生：拥抱云原生-云计算生态系统