什么是user story？

是一种促进场景化思维方式的工具，目的是训练大家“先思考场景，分析问题，再讨论解决方案”的产品工作方式。
User story的形式通常为一句话：

User story - 图1
<角色>who: 谁使用 （尽可能具体）
<活动>what:要完成什么活动 （每个用户故事都是唯一的；是主动语态而非被动语态）
<价值>value:为什么要这么做，价值是什么

理解用户的行为场景：

  1. ta为什么要做这件事？
  2. 如何做的？之前经历了什么？现在正在经历什么？接下来要往哪里去？
  3. 在这个过程中他遇到了什么问题？
  4. 我们如何能够帮助他解决遇到的问题？或者提供更好的解决方案？

用户故事示例：
<标题>：创建物品到达客户时的自动发送短信
<内容>：作为【客户】，我想[ 在物品到达时收到短信 ]以便[ 我可以马上去拿货物 ]。
<验收>: Given 货物运送给客户, When 货物到达客户收货地址，Then 可以立刻去拿货物；
用户故事将为【客户】带来价值；满足其 [当物品到达时接受短信]的需求；这个是可以实现的用户故事[客户利用短信去拿她购买的物品]。
#图片来自网络，侵删#

用处

  1. 帮助团队理解用户场景，促进共识的达成

  2. 有助于验证假设和需求 User story - 图2

    好的user story的衡量标准是什么

    INVEST原则：

    好的用户故事必须遵循INVEST原则即：Independent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimate（可评估的）；Small（小的）；Testable（可测试的）
    1）Independent（独立的）：每个用户故事间应该相互独立
    2）Negotiable（可协商的）：用户故事并非合同，只是对需求的简短描述，在一开始不适宜包含过多细节，具体细节在沟通阶段产出。
    3）Valuable（有价值的）：每个故事必须是对客户具有价值的，因此应该站在用户角度进行编写。
    4）Estimate（可评估的）：对要进行开发的User story 进行粗略估算，以便团队知道userstory的工作量。并由PO决定是否需要重新设计user story或进行任务拆分。
    5）Small （小的）：一个好的用户故事要短小，不要过于庞大。最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
    6）Testable（可测试的）：用户故事应该是具体并且可测试的。如果用户故事过于含糊，测试时候就没有标准可循。例如：软件要易于使用。

    建议阅读

  3. 清华大学出版社《洞察用户体验方法与实践（第二版）》P469-494

  4. 人民邮电出版社《用户体验可视化指南》